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ABSTRACT 



in order to enforce the security of the information 

stored in a computing utility, it. is oseesmsaasy- to certify 
that tftv prelection mechanism is correctly jjb|i I ssmml ail so 
that- there es&et : *o uncontrolled access path to the stored 
information , Certif icetsios" 1 requires -th**i thee -mmmmr&ty 
kernel' be much a»»ller and simpler tJian the supervisor of 
present general- 'purpose operating systems. This .thesis 
explores one- aspect of' improving 4JM£*mmj&&l&mM&ltir of- a 
computing utility by designing a dynamic JLlnher that runs 
outside the security kernel domain. 

The dynamic linker is designed to run in any user 
protection domain of a multidomain computing utility. It 
is shown that the dynamic linker never needs the privileges 
of the security kernel to properly operate. In particular, 
the thesis demonstrates the ability of the dynamic linker 
to link programs together across domain boundaries without 

violating the protection of either domain involved in the 
operation . 
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I . Introduction 
1. Security Kernel 

The concept of computing utility deaicmateQ a computer 
system or a network of computer "systems' dedicated to ser- 
vice a community of users ill. $km ,■.*$?% ©£ the computers, 
of the services rendered and of the community of users may 
vary widely. Yet it remains that in all cases one of the 
most important features of the coipput^ng utility is to 
provide the users of the community with the ability to share 
the resources of the system. We will be specifically con- 
cerned about sharing the i^fQsgjftio* stored in the compu- 
ting utility. Different members of the community of users 
may have different intention* wjh|.eh are in conflict with 
one another with respect to the Stored information. Some 
user might willfully or accidentally access (use, steal 
or modify) the information kept by another user in the 
computing utility. Hence uncontrolled sharing of all 
information poses a direct threat to the security of the 
information and to the privacy of the individuals con- 
cerned by the information (2-6) . 

In order to enforce the security of the information 
and to safeguard the privacy of the individuals concerned 
by the information, the access to the stored information 
must be controlled by some protection mechanism (7-11) . 
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However, no protection mechanism will serve our purpose 
unless it is taruaifeed> by its. UMKNfU.. Several features -of a 
protection mechanism contribute, *» ma** it, reliable C6,15). 
It is not our purpose h;er» t<^44»^»i%i^ FW 1 ,*9 :<:^M*-% these 
features . Only one of them is ^ .ifl^erfjl^ tp us, : the 
certification of correctness of . £ thf..j^:o,te^tipn mechanism. 
Certification of ico^reotne;** xfuaraat*** .that the protection 
mechanism complexly • controls, jlOie^acc^f*^ .,thja ftpred 
information/that it is an ^ ef f eoHvf| ,^mft|em^|^tion of the 
desired protection scheme* and that .t^er^ ,is no way a user 
program could subvert , fiir^umyeBt c or.-,mp^fv, it to gain un- 
authorized access to the ^tored.info^mfUQn? Certification 
of a protection mechanism;, is the result ,of ;? 'a careful audit- 
ing of each component coatribu^ng to. *^f ; project ipn of 
the stored information. Such auditing apt pnly 4nc|.udes 
a verification of the in^^pn^and^l^lm^^^^ of 

each component of ~ the ? j proteC:'^^, : , a ec J ^an^s» 8 buj^als o a ver- 
ification that interaction* among, thern^ .and with, the outside 
world cannot cause ma^funct^oa or , unejqpe^fd behayipr 
resulting in unauthorized; acoesji ,.Jx^. inform^^ipn. 

The protection mechanisms. *rj% ^^^ ic ^pplemei\ted by a 
combination of hardware, and spjpwiar^ fe3f fh^,. programs and 
data bases of the software {^rfaifoa -ar^ ^ m*& sensitive 
part of the computing utility, for ^^tc ? 1 ^ 37 ^ who qan 
access what information. A§ a result* this, protection 
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sof tware roust be isolated from and protected against other 
programs in the computing utility. »#f -psrOtectioii software 
component, if tasf>ered with, ceroid cause unauthorized 
accears to stored information. Sfenoe,' usear ■■ programs must 
be prevented from modifying, sutwwrtijig.-or circumventing 
the protection software . Sue* 4fcfltitiMMMl»t 'm&mM provide 
a complete control over the interaction* Between the pro- 
tection software and other programs in a computing utility. 

The security kernel of a computing utility is that 
part of the software which could, as a result of a bug or 
malicious alteration, cause unauthorized access to infor- 
mation. Thus it is the programs and data baaea of the 
protection software plus any other p*ogwasW (and data 
bases which control their behavior) that have direct 
access to the protection software. 

In most systems the security kernel corresponds closely 
to the supervisor. It includes a great many programs and 
data bases that are not functionally part of the protec- 
tion software, ks a result, the security kernel is much 
larger and more complex than the subsystem which implements 
the protection mechanisms . Thi s is unfortunate , becaus e 
it is the entire security kernel which must be certified 
to establish confidence in the security -of stored infor- 
mation. Extra size and complexity make certification 
more difficult. 
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This thesis will explore one aspect of making the 
security kernel of a computing utility smaller, simpler, 
and thus more certifiable by developing a system design 
in which the linking function is outside the security ker- 
nel . The linker of a computing utility is the program 
responsible for binding together separate procedure and 
data modules to build larger program elementis. In current 
systems, the linker is almost always part of the security 
kernel, but as will be demonstrated in this thesis, is not 
part of the protection software. Removing the linker can 
significantly reduce the complexity and the size of the 
security kernel. 

2. Dynamic Linker 

In writing a complex program, it is extremely desirable 
to subdivide it into several modules. In doing so, the 
complexity of the programming task is reduced for the 
modules can be programmed and tested independently and 
existing modules may be incorporated into new programs. 
The idea Of modularity implies the existence of some mech- 
anism to assemble modules into larger programs. The 
writer of a module must be able to connect his module to 
others. One simple Way to achieve the connect ioir is to 
give a symbolic name to each module and to denote it by 
that name in other modules. This establishes a symbolic 
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link between the two modules. The problem is that symbolic 
links are meaningless for the hardware of the processor. 
For a symbolic link between two modules to become a snapped 
link usable toy *be processor, the *yj^lie name used by 
the programmer must be translated into the latjfocal. (hard- 
ware intergretable) address of the module denoted by the 
symbolic name. When used to combine separately compiled 
modules translation is called linking. The program which 
takes care <©f the translation is called the lijsteer. 

There exists a wide variety of linkers which iWe win 
not describe here (12) . Often a linker is invoked when a 
program is loaded into primary memory. Before control is 
given to that program, each symbolic name it usee is 
translated into a logical address by the linker. In 
other schemes, control is given to a program module as 
soon as it is in primary memory. When execution of the 
module hits a symbolic name, a hardware event (fault, inter- 
rupt, trap) triggers the linker execution to translate the 
symbolic name into a logical address. Execution resumes 
after the link is translated (snapped) . This type of 
linking is called dynamic linking and is carried on by a 
dynamic linker . It is more flexible and saves the cost 
of loading into memory and linking together modules 
which may not be used by the program every time it is 
invoked. Although the rest of our thesis will be talking 
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about dynamic linkers, the results of the research are 
also applicable to regular linkers. ■The problem is more 
challenging for dynamic linkers precisely because of the 
dynamic aspect introduced by the hardware events. 

3. Background 

Certification is a relatively recent topic in the field 
of computer science. Many authors have occasionally men- 
tioned the need for certification, as we did here. But 
there exists no concensus on the best way to certify a 
large software system. The area < is not very well struc- 
tured and much work has still to be done to organize it. 
Yet most of the papers on that topic seem to agree that 
whatever hypothetical method is used to audit and certi f y 
the security kernel, the correctness of a "simple" kernel 
will be easier to verify than the correctness of a 
"complex" kernel. A small number of modules, strict con- 
straints on the interactions between the modules, method- 
ical design, systematic implementation, precise supporting 
documentation, simple language constructs, formatting and 
readability are factors likely to simplify the task of 
auditing the security kernel. ConverseJ.y> a large number 
of modules will undoubtedly complicate the problem. In 
addition, it is likely to increase the number of inter- 
actions to worry about. Complexity and sophistication of 
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the module* themselves would also make auditing harder. 

A good guideline when trying t» simplify the security 
kernel is the principle of least privilege,, Xhis princi- 
ple is the equivalent of the military "need*-toHtnow w rule. 
It states that any program module should he granted just 
the privileges it needs to properly operate and no more. 
Modules of the security kernel should be granted the 
privileges* <s£ tile security kernel., on the basis that they 
contribute to the protection of the stored; information. 
Module* not contributing to * the protection* goal should 
not be able to use such privileges. Seeping these inside 
the security kernel increases ■ the".; sise and compleacity of 
the kernel and brings in fim«taionJ^:.am©V>eone^iM^»'.'.that. are 
hard to validate with reepect to the- protection goal ©f 
the kernel- Keeping them outtride ...the ■ kernei .cuts down on 
the number of: modules and interactions to- be coasdbdered 
as- part- of the-; certif ioatioa: .procaee*.. A module" cannot 
abuse privileges it doesa * t have to- -modify , ciafcumweat , or 
subvert the security kernel ©psratioiii... 

4. Motivations 

Besrignirag a dynamic linker to -ism,-: outside the security 
kernel environment of a computing! utility i» motivated by 
the desire to improve the certif&afefcL^tv^ ©f the protection 
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mechanism in the system under concern. A linker is char- 
acterized by four features which ''suggest ^ it should run 
' outside' 'the security "kernie^ : l5lr*th%^ the 

auditing 6# the kernel. 

Firstly, a linker does h6% li|^teTfcilft any concept re- 
lated to the protection of '0& J *^teif; u or helped to support 
the protection mechani sins. 

Secondly, in view Of the function implemented by the 
linker , ' it ' seems reasonable "to"" "suspect" 1 tha^'' : the r . linker 
does hot need any of the privileges granted to typical 
modules of the security kernel, therefore', the least 
privilege principle implies that the linker be outside the 
security kernel. 

thirdly, a linker is llf giliiirai" a velr^ colpplik program. 
Even though its function is easy to describe, the details 
of its implementation fetfuire v the""use 'of intricate and 
sophisticated language constructs" which Wake the reading 
and auditing of the program a quasi imp^irili1$le tksk. 

Finally, the linker, by its very nature handles data 
directly accessible to the users of the sys'tlsto. Such 
data could co%taih^- pWp^ 
capable of causing thiliri^e^^W 

unexpected operations. &^ , ~'tf$ffic££ l &Stfc. "i-t is much 
harder to verify the correct" opier^iori "oif a px^g"raift when 
it can be presented with *aji' v arWitif.alry"'"iMlpd€ tMan to verify 
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correct operation when a "correct" input is guaranteed. 
Since malfunction and unexpected behavior are ruled out 
for program components of the security kernel , very 
sophisticated machinery would he required to verify the 
consistency of user requests to the linker and insure 
proper operation. Even if such machinery were available, 
it would only increase the complexity of the linker. 
Again we come it© the conclusion that the linker should 
not be part of the security kernel,, if so, no malfunction 
of the linker will ever subvert the protection mechanism 
of the system and cause unauthorized access to protected 
information. 

To summarize our motivation we can say that designing 
the linker to run outside the security kernel environment 
of a system is a step towards simplifying/ isolating and 
better defining the security kernel, thereby making its 
auditing easier. 

5. Objectives 

The motivation for our thesis is based on four argu- 
ments which suggest that the linker should run outside 
the security kernel environment of the system. The first 
objective of our thesis is to show that it can run outside 
the security kernel. We will have to show that the linker 
indeed does not contribute anyhow to the protection of the 
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system and is never needed to support the operation of the 
kernel. We also will have to show the inverse relation; 
that is, the linker does not use or need any of the priv- 
ileges of the security kernel modules. We eventually will 
have to show that the idea of forcing the linker to exe- 
cute outside the security kernel environment does not 
introduce any unsuspected, unsolvable problems. 

Clearly we would not pay so much attention to our 
problem if its solution were obvious and if all linkers 
known today were running outside the security kernel 
environment of the system for which they were designed. 
There exist a few systems (13) where the problem has been 
solved. However, it was solved only for the very simple 
case of a static linker binding modules together inside 
one protection environment . Instead our thesis will pro- 
pose a general solution of the problem for a dynamic 
linker binding modules together across protection environ - 
ment boundaries . The design to be proposed can be applied 
to any type of computing utility with some variations 
which we will eventually mention when appropriate.' 

Except for a few cases already mentioned, all systems 
are designed with their linker being a component of the 
security kernel, and having the privileges of the security 
kernel (14) . The second objective of the thesis is to show 
the feasibility of the design to be proposed for a 
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particular real world system. We have chosen to remove the 
linker of the Multics (Multiplexed Information & Computing 
Service) (15-18) system from the security kernel environ- 
ment and to force its execution into the user environment. 

The linker presently runs in the environment of the 
security kernel of Multics as do many other components of 
the system which do not belong in the security kernel either. 
The main reason for this design was that the cost of 
dynamically changing the protection environment of a 
computation was prohibitive in the initial version of 
Multics. Hence, it was decided to include many system 
components in the security kernel that were not part 
of the protection mechanisms in order to minimize the 
number of times the protection environment was* changed 
in the course of a computation. Snapping a single link 
requires two environment changes with the linker inside 
the security kernel, but may require 10 to 100 with the 
linker outside. A second version of the Multics hardware 
(15) has reduced the cost of a change in protection 
environment to the level of a normal interprocedure 
call. As a result, there is no longer an economic 
incentive to leave the linker in the security kernel. 
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Before we go on to develop the design we will mention 
a third. objective of the hitimtiMr .■ In xmtm&nfr; the dynamic 
linker from the security kernel of Mulfcics* we hope to 
establish a few more criteria for deciding whether or not 
a program belongs in the security kernel of a system. We 
also hope to better define what general programming fea- 
tures contribute or hinder the task of removing, a program 
from the security kernel. These lists of criteria and 
features of interest will certainly be as helpful as the 
removal of the linker itself to better define the security 

kernel of a computing utility in general and of Multics in 
particular. 

6. Plan of the Thesis 

Before we come to the body of the thesis we would like 
to briefly describe how we will develop the research and 
carry it on to the detailed implementation of a linker 
running outside the security kernel of a computing utility. 

Chapter II will develop a computing utility model where 
emphasis will be put on features directly relevant to our 
research. The model will serve as a basis to describe the 
design and it will help the reader to apply the design to 
different systems by matching the model with that system. 

Chapter III will propose a complete design of relevant 
parts of the computing utility. Problems encountered in 
the design will be discussed and solutions will be proposed. 
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In Chapter IV we will demonstrate the feasibility of 
the proposed design by describing its implementation on 

Multics. 
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II. A Computing Utility Model 

In order to better define the features of the design 
we will propose, and to generalize its applicability to 
any computing utility, we will describe a computing utility 
model. This will enable us to explain the proposed design 
in terms of the model. It will enable the reader to apply 
the design to any specific computing utility by matching 
that computing utility with the model. 

We will develop the model in two steps. Firstly, we 
will describe a protection model suited to the environment 
of a computing utility. Secondly, we will build on top of 
this model an information storage model suited to the 
needs of a dynamic linker. The model will help us tb 
better define the concepts of protection environment and 
logical address space which we have occasionally mentioned 
but have not carefully defined yet. We then will explain 
in detail the operation of the linker in terms of the 
model. This will greatly simplify the subsequent descrip- 
tion of the design of a linker running outside the security 
kernel of a computing utility. 

1. Information Protection Model 

In order to better understand and study the problems 
related to protection of stored information, several 
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structural and mathematical models of protection schemes 
have been proposed (19,20). We will briefly describe here 
a model based on the concept of protection domain (21,22). 
This model will help us understand what is meant by a 
protection environment and particularly what the security 
kernel environment is. 

For the purpose of our discussion, we will talk about 
the environment of the computing utility in terms of 
objects and subjects. Objects are passive. They are the 
information containers of the computing utility. They 
must be protected to prevent unauthorized access to 
stored information. Objects are the procedures and data 
bases stored in the computing utility. Subjects are 
active. Subjects are the internal representation of users 
of the computing utility. Subjects, sometimes called 
processes or jobs, act on behalf of users to create, 
delete, modify, use and manipulate objects. 

Subjects can access objects by means of capabilities. 
A capability is an identifier denoting some object in the 
computing utility. Any subject possessing a capability 
for an object is entitled to access that object. 

The set of capabilities available to a given subject 
defines the domain of execution of the subject. The domain 
of execution of the Subject is the protection environment 
where the subject operates. 






"■"WV^^^flWKdfcSSMB^^jgfse^^ » : 



-23- 

When a subject changes domain of execution, it changes 
its set of capabilities. He can enter a new domain of 
execution only through a gate. A gate i« a procedure 
object which forces entrance to a domain to coincide with 
invocation of certain procedure objects in the domain. 
These procedures completely determine the activity of the 
subject in the domain. For a given subject/ a gate is an 
entry point into a given domain. However, for two 
different subjects, the same gate object leads into dis- 
tinct domains. We make the assumption that each domain 
can be entered by only one subject. Thus when two subjects 
wish to enter the "same" domain, they -are actually 
installed into distinct domains containing' equivalent sets 
of capabilities. 

With this model in mind we can better talk about the 
environment of the security kernel. For each user compu- 
tation, i.e. for each subject of the computing utility, 
there exists one dbmain-the security •'kerrielr domain (23,25)- 
where capabilities exist for the subject to access pro- 
cedure and data objects of the security kernel. Access to 
the data objects is constrained by the access pattern 
encoded in the procedures of the kernel. Access to the 
procedures is further restricted to certain entry points: 
the gates into the security kernel domain. Hence complete 
control is gained on the interactions between the kernel 
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and tiie outside world. The security kernel is a so called 
protected subsyste m, (24,25) an instance of which exists 
in the first domain created f or each subject in the corn- 
put ing utility, 

2. Information Storage Model 

The jrreylows paraprafth* 1mm-. made ■pore .precise, the 
notion of protection eps&cesssiat. . «e will iw consider 
the concept of logical address -specs.. r 

The set of aj.1 objects in a computing utility con- 
stitutes the $£teJS8&SeL* t *** oopp»ti|>g utility. Among 
these object* is a., particular set ; M •Qbjffi^s caJJLed 
catalogs . Catalogs are .data bases a^tmimtew .descriptive 
information about .some set of ohjeactSr One. of the items 
contained in a catalog about each object described in that 
catalog is the physical address 9$. each^43bj#e|t. The 
ph y s ^^ j*^*** of ** object defines where, the object is 
located on some, memory devies attained ,to the^jepaputing 
utility. The physical address of an object must be clearly 
distinguished from its logical a d dres s. The logical 
address of an object is the address by which an existing 
subject .references the objects . Qwiy. logical; .Addresses are 
meaningful to . |«ooess©rs executing machine, code. . . An 
object always has a physical address even when it resides 
on secondary storage and no subject uaes it. But it may 
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not have any logical address if no subject uses it. 
Assigning a logical address to an object on behalf of a 
subject is the role of the file system manager (FSM). 

When a subject wants to assign a logical address to 
an object, it must pass to the FSM the unique identifier 
of the object. !Fhe unique identifier of U object can be 
a unique name, a unique number, or a cataiog unique iden- 
tifier and the symbolic name of an nh-^r^ ^ +h a + ^j-^^ 
Unique identifiers are different from symbolic names in 
that more than one object may have the same symbolic name 
as long as they are described in different catalogs, but 
no two objects can have the same unique identifiers. 
When given a unique identifier, the *Stf performs two dis- 
tinct functions. Firstly, it searches the file system to 
find the description of the object tonoted by the unique 
identifier. If the search fails or if the FSM decides that 
the requesting subject does not have the right to know about 
the object under concern, an error message is returned 
and no action is taken. If the search succeeds and the 
requesting subject has the right to know about the object, 
the FSM maps the object into a logical address of the 
address space currently seen by the subject (enables a 
logical address) , remembers the binding between the 
unique identifier and the logical address, and returns- the 
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logical address to the subject. 

One question is now in order. What is the real 
nature of a logical address? Since the FSM, a component 
of the security kernel, releases logical addresses on the 
basis of a protection decision, a logical address is 
merely a capability to access an object. As long as a 
subject has no enabled logical address for an object, it 
cannot reference that object. If and when a logical 
address is enabled and delivered to the subject by the 
FSM, it gains access to the corresponding object, i.e. it 
has a capability for that object. This establishes the 
connection between our information protection model and 
our information storage model. 

This connection between the two models brings up the 
question of the nature of the logical address space. Since 
a capability for an object is granted to a given subject 
in a given domain, one might wonder whether the logical 
address allocated to the object is valid Only for that 
subject in that domain. In other words, once a logical 
address is assigned to an object for some subject in some 
domain, will that subject see the same object at the same 
address in other domains? Will all subjects see the same 
object at the same address in all domains? The answer to 
these questions depends very much on the type of logical 
address space supported by the system under concern. In 
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the simplest case, where the logical address of an object 
is its primary memory address, if any, then we can talk of 
a system wide address space. Once an address of the space 
is allocated to an object, all subjects in all domains 
will see that object at that address if they have access 
to it. On a virtual memory system, each user, i.e. each 
subject may have one address space of its own. When an 
address is allocated to an object in a subject address 
space the subject will see the object at that address in 
all domains where he can access the object and the address 
will be meaningless (not usable) in other domains. But 
all other subjects may or may not use the corresponding 
address of their own address space for the same object. 
Finally in some systems, there may be one address space 
in each domain. Such is the case, for instance, of base 
and bound machines. A domain is defined by the base and 
the bound of its address spacla . A logical address is 
mapped into a physical address by relocating it relatively 
to the base and within the bound of the address space of 
that domain. Once an object is mapped "into one address 
space, the address space of another "domain may or may not 
contain the same object at the same logical address depen- 
depending on what its base and bound are. To conclude this 
discussion, we will assume for the rest of this thesis, 
that the concept of address space, when unqualified, means 






-28- 



the address space seen by the gives subject in the given 
domain. Unless specifically stated, no assumption will be 
made about who can see the same address space in what 
domain. 

3 . A Dynamic Linking Model 

The last paragraph described the models we will use 
to support our design. Before we move on to- the design 
itself we will describe the detailed operation of linker 
with respect to the models. Xn doing so, we will not have 
to worry about what a unique identifier, a logical address, 
a domain, or a gate is. fie know that all. -these concepts 
can be identified in any computing utility and that our 
description can be based on them without ambiguity. 

whenever a subject executing an object encounters a 
symbolic name of , or a symbolic link to another object, 
a hardware event called a link fault occurs. As a result 
of the link fault a copy of all machine registers, called 
the machine status , is handed to the linker. 

The first task of the linker is to analyze the machine 
status to determine which symbolic link caused the fault 
and which object was being executed at the time of the 
fault. This object is called the faulting object . The 
domain where it was executed is called the faulting domain . 
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By searching the faulting object, the linker will find a 
complete description of the symbolic link and in particular 
the symbolic name associated to the link which designates 
some object of the environment. This object is called the 
target object of the link. The domain in which it belongs 
is called the target domain . 

The second task of the linker is to search for the 
target object in the file system and to map it into the 
logical address space. In order to do this the linker 
will of course need to invoke the FSM. The search is 
driven by so called search rules . Each domain has 
associated with it a different set of search rules. 
Search rules are an ordered set of catalog unique iden- 
tifiers. Of course, it is irrelevant to talk about search 
rules when the file system is one single catalog. However, 
in general, it contains many catalogs. The search rules 
force the linker to search only some of these catalogs 
in the desired order. The linker takes one search rule 
at a time, combines it with the symbolic name of the 
target object thereby making an object unique identifier. 
The linker hands the unique identifier to the FSM to search 
the file system. If the search fails, the FSM returns an 
error code to the linker. The linker will keep trying 
the next search rule, if any, until a search succeeds. 
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In this case the PSM returns the logical address of the 
target object to the linker. 

The third task of the linker is then to translate 
the symbolic link into a snapped link usable by the pro- 
cessor. This is called snapping the link . The linker 
just replaces the symbolic nai»e in the link by the 
logical address of the target object. 

Finally the linker must modify the machine status 
to force the executing subject to X99*w. the now snapped 
link. 

By a mechanism external to the linker itself, the 
machine status is then restored so that the executing 
subject jumps back to where it was just before the link 
fault. 

Once a symbolic link is replaced by a logical link, 
it will no more cause any link fault for the current 
subject in the current domain. 
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III. Design 
1. General 

The last chapter presented a computing utility model 
which will be used to support the discussion of the design. 
The steps in the operation of a dynamic linker have been 
described. As it should now be clear to the reader that 
programming the linker itself is a feasible task, the 
current chapter will rather concentrate on the problems 
of inserting such a linker into the overall design of a 
computing utility such that it be outside the security 
kernel. The next chapter will then present a test case 
implementation of the design to demonstrate the use of the 
model in identifying the components of a real system and to 
show the feasibility of implementing the design on a real 
system. 

In developing the discussion of the design we will 
try as much as possible to progress naturally and to 
handle each problem as it shows up. In a first section 
we will explain how the security kernel can operate 
without the help of the dynamic linker. In the remaining 
sections we will demonstrate that the dynamic linker can 
operate without the privileges of the security kernel. 
This order of discussion coincides with the order of 
events when a computing utility is brought up into 
operation: the security kernel by its fundamental 
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purpose is the first subsystem to be operational and is 
used to brine; up the rest of the system functions, the 
dynamic linker among others. 

Me do not claim in any wry that the design to be 
outlined is the only possible design solving our problem. 
By its very nature, the topic of the research poses 
several structural problems which axe easy to identify 
and to describe. However, designing solutions to these 
structural problems cannot be done systematically as 
would be the case for mathematical problems. Solutions 
to a particular structural problem may bring up other 
structural problems. It is hard to predict and to control 
the propagation of the effects of a particular solution 
to a particular problem. HmncB it is hard to estimate a 
priori which solution minimises the number and the mag- 
nitude of hidden potential problems. As it is impossible 
to discuss all solutions in detail, we will attempt to 
justify our choice between different solutions whenever 
possible, and especially where a sophisticated solution 
has been prefered to an apparently more obvious one. 
Even so, we do not claim that all possibilities will be 
discussed. We are convinced that equivalent designs could 
be proposed. We believe only that our design is among 
the simplest ones. 
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Finally, we will attempt as much as possible to be 
sufficiently precise in the discussion of the design to 
convince the reader that subsequent implementation is 
practical and straightforward. At the same time, we will 
try to remain sufficiently abstract to enable the reader 
to implement the design on any general purpose computing 
utility. 

2. Security Kernel Initialization 

Before any user can request service from a computing 
utility, the system must be brought up into operation. 
This initialization task is done under the responsibility 
of a subject called the initializer. The initializer must 
cause the loading and set up of all programs required to 
support the operation of the system. The first of all 
subsystems which needs to be initialized is the security 
kernel because of its fundamental function: generating 
other subjects and domains for these subjects would be 
impossible without an operational security kernel. We 
are concerned about one aspect of making the kernel 
operational. Like all subsystems in a computing utility, 
the security kernel is a modular program. Hence its 
operation does require a linking function to combine the 
modules together. However, our objective is to propose 
a design where no dynamic linker exists in the security 
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kemel domain. The security kernel is not allowed to cause 
link faults . Hence all link* of the security kernel must 
be snapped prior to the operation of the kernel. This 
task is .part of the security kernel initialisatio*u 

Linking together all modules of the security kernel 
requires the help of a static linker. Essentially two 
types of static linker could he used: a binder or a 
prelinker. The binder is a static linker which prepares 
once and for all a fully operational security kernel 
that can be used without any further initialisation as 
many times as desired . The prelinker is a static linker 
which links the modules of the security kernel together 
each time the system is stacked, during an initialisation 
phase. He will not describe the detailed design of either 
a binder or a prelinker. This topic is below the level 
of our discussion. We will ask the reader to realize that 
writing a static linker is feasible in many ways. We 
will just discuss the properties of each type of static 
linker. 

The technique of the binder seems both simple and 
economical. It is economical because the links of the 
security kernel are snapped only once for a given system 
version and the resulting operational security kernel can 
be reused as many times as desired. It is simple because 
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auditing and certification of the kernel must be done 
only once on the final operational kernel. The binder 
is kept outside the environment to be certified; only 
the results of its operation are to be audited. 

The technigue of the prelinker instead reguires that 
the prelinker be audited and certified. Since domains 
are meaningless until the security kernel is initialized 
to support them, the virgin environment seen by the 
initializer may be viewed as just one single domain 
bound to become the domain of the security kernel. Con- 
sequently the prelinker of the security kernel which is 

■ '■■ ?t,- -«■.-, r ..-.-.. ;■.•■ ., ■ ' ■...•'.,.,. .;x0rr sol) i-;»f-: ■•;.>.. -.- ;.-■ . , 

executed prior to any module of the kernel is in some 
sense a component of the soon-to-be kernel. The pre- 
linker must therefore be certified. By now the reader 
may wonder what is gained by the prelinker technigue. 
We want to remove the dynamic linker from the security 
kernel but we propose to keep a prelinker in the kernel. 
Firstly, the use of a prelinker may make the system 
initialization more flexible. The use of a binder fre- 
quently implies that not only the version of the system 
but also the initial configuration of the system (hard- 
ware configuration and sizes of various supervisor tables) 
always be what the binder assumed. Instead, in the case 
of the prelinker, even though the version of the system 
used may always be the same, the configuration of the 
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system may be changed each time the system is started by 
properly notifying the prelinker of relevant configuration 
data to be respected. Thus a prelinker is more flexible 
than a binder. 

Secondly, believing that the certification of the 
prelinker is just as bad as the certification of the 
dynamic linker is wrong. By its dynamic aspect, by the 
requirement that it be able to deal with objects scattered 
in a large file system, and by the fact that it may support 
miscellaneous sophisticated linking features needed by 
user programs (see next chapter) , the dynamic linker is 
a much more elaborate program than the prelinker. The 
prelinker is a static linker; it deals only with objects 
of the supervisor concentrated in just a few well known 
catalogs of the file system; and it may not support 
sophisticated linking features because security kernel 
modules, unlike user modules, may be programmed to avoid 
such features. In addition, by its very nature, the pre- 
linker is an atomic program while the dynamic linker is a 
modular program. All such factors make a prelinker a lot 
simpler and hence easier to certify than a dynamic linker. 
Finally since the prelinker is needed only during 
initialization the security kernel can discard its own 
capability to ever again access it during regular system 
operation. Thus the prelinker cannot be executed again 
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once the system is initialized, and therefore it cannot 
hurt the system. This also simplifies the problem greatly. 

Consequently, the choice between binder and prelinker is 
a choice between relative certifiability and flexibility. In 
general this choice is independent of where the future 
dynamic linker will be running. Since the implementation 
to be described in the next chapter is based on the pre- 
linker idea, we will assume the same idea in this chapter. 
However, we acknowledge the fact that using a binder is 
most probably equivalent as far as our thesis is concerned. 
We will now temporarily abandon the operational security 
kernel we have obtained. The next section will first dis- 
cuss a few design principles an<S theih carry on the develop- 
ment of the system by building other domains around the 
security kernel. 

3. Dynamic Linker Initialization 
a. Design Principles 

In the previous section, we have shown how the 
security kernel modules can be linked together without the 
help of the dynamic linker. Once linked, they no longer 
need any linker, thus they can operate without one. The 
rest of this chapter will examine the oiher side of the 
design. It will be demonstrated step by step that the 
dynamic linker can operate outside the security kernel. 
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It seems that the first problem we encounter is to 
define what "outside" means. One half of our design is to 
remove the linker from the domain of the security kernel. 
The second half of it is to decide in which other domain 
or domains the linker will run. 

It seems very appealing to simply install the linker 
once and for all in a domain of its own (see figure 1) where 
a subject will be able to go if and when necessary. Even 
though this solution may seem clean and obvious, it is very 
likely to raise implementation problems. Indeed, on each 
link fault, the linker domain would have to be provided 
dynamically with appropriate capabilities to access the 
faulting object, and perhaps the target object or even 
other objects in the faulting or the target domain. When 
the dynamic linker was always running in the same domain 
and that domain was the security kernel domain, providing 
it with dynamic capabilities was easy given the unique 

privileges available in the security kernel. However, 

j '''■,' - ■ 
this is no more true if the linker runs in a domain 

different from the security kernel domain, Furthermore, 
a linker domain containing capabilities for objects in 
several domains, even if only one at a time, can poten- 
tially operate as an unauthorised information channel 
between these domains if it malfunctions. Therefore, such 
a linker must be certified to prevent potential unauthorized 
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Figure 1: Different environments for the linker 
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access to the information. 

A second potential answer can be found by thinking 
in terms of capabilities. Since the linker will need to 
access objects in the faulting domain and perhaps in the 
target domain, both domains seem potential candidates to 
host the linker. The target domain is actually not a 
good candidate because it is not determined until the 
target object is identified. Hence it is undetermined 
at the time of the fault and the only domain where the 
linker could initially run is the faulting domain which 
is easily determined by the machine status. 

Consequently, even though we do not definitely reject 
the first solution, we strongly recommend and will fur- 
ther assume the second solution which at least guarantees 
easy access to the faulting domains and eliminates a 
security threat. It will be seen that access to the 
target domain is usually not required and eventually easy 
to provide. In the above discussion we have identified 
the major problem of removing the linker from the security 
kernel domain: it no more has all the privileges to access 
any object in any domain; each particular invocation of 
the linker will see access capabilities constrained to 
those of the faulting domain for the invocation (see 
figure 1) . 
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We have just decided to design the linker to run in 
"the" faulting domain. Since any domain is a potential 
faulting domain except for the security kernel domain, the 
linker must be made "available" in all domains except the 
security kernel domain. The second problem which we will 
now discuss is the notion of availability of the linker 
in a domain. What does availability of the linker mean? 

Firstly, it means that capabilities must exist in all 
domains, except the security kernel domain, to execute 
the linker. Providing such capabilities in each domain 
is rather trivial and should pose no implementation problems, 

Secondly, a dynamic linker, like most programs of a 
computing utility is a modular program. As such proper 
operation will be possible only if there exists a means 
to snap links between the various modules involved in 
dynamic linking. For most programs in a computing 
utility links can be snapped dynamically. In the case 
of the dynamic linker, this proposition is nonsense: 
if the dynamic linker contains unsnapped links, it is not 
operational and cannot count on itself to snap its own 
links. Hence a static linker must be used to link the 
dynamic linker modules prior to using them. As long as 
the linker was part of the security kernel, its modules 
were linked together by the prelinker of the security 
kernel. Now we have removed the linker from the kernel, 
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it will no siore -'tee aufceawt&eally #*a^iaaieed.. Hence, its 
modules must scsnehow be linked together independently to 
make it^epa*eti«nel .in oth»r daaaiin. He aw <ask ourselves 
what *©rt «S SUfei'«ttit An' the dynan i c linger and bave 

to be ^anafqp^' : «fe»*i i csaa.iar..' ; l*»^3Jaaflra«r- i« a «t of proce- 
dures -an* data s©d»l«s which according to our objective 
can be ie*een**d .in- any idftejelev ; <eejee4p*i tibe » mmmci&f' kernel . 
domain . ' : CieaMfcy at leaet all a&aldfc- l>fti tw e ejft theee eodules 
must be *n«i!peli : '-t© : ensure proper operation. In addition, 
'the <ea£iai«r <de*^i#ti©m of the milflear ^ap«ei^fettn^:»WHastiQned 
the; aeaa %o< iwfcoke tia''tii. : ' i ©ia*sji^%hi! ^Ifcateer H« anywhere 
but -in. tfce. 'eacuritsy -kernels *t ««»■*- i»**ifce ifch* •:-»Mt i *im&y ; 
-through : one- or «»re gatee .infc© - fJtiiP /SiiijarA^ lMMt. : : : : - Hence 
there will «•&•*. links to^t&oae #*£***- iHe^sisjfc: also .be 
snapped. «0enssejttettt9grw ■■**• siigbfltibLon- eeft'<<fe» p&fi*a«ed by 
figure 2 . Each ^domain lias ' oapefei 11 ti»« , like domain p , 
to execute **be'*' liiifleer.. ♦Ike" Mmkek 'ito.'***- .set osf all 
procedures and data bases i»ittia*rtdiea*y .ixm$m$: iar^dpiaiBically 
linking two Modules. *he leaker "hOUd MBQ*itoa*fi* one or more 
links to *«e*irity - kernel -gatae.. -Iloti.ee ^lEbWt-- thews 'gates , 
as -kernel raMponentfl , .are' *g»«rjM©ss& , *e* 4av jfixsHnr pr e- 
litiked to -^fbexJHft.1 ^Mod^aes of tHe 4a*jfeefe'<4ixteg «sy^bem 
initiali.a»i4a.on'.. Hence ,we ,? «© not *»«%'«& *©is*y ^bout them 
anymore -even- though tsttey ^ajmNta -<&&•*• -tofebe inwod^ed in 
dynamic linking. 
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Figure 2: Linker and security kernel 
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b . Prelinking the linker 

We aire now in a position to discuss now static 
linking of the dynamic linker can be dona. Me had left 
the development of the system at the stage where the 
security kernel was operational in the fi£st and only 
domain of the environment. We will now pursue that die- 
cuss ion and axami the gptt^Tfttin solved with making 
the linker available in new domains around the security 
kernel domain. 

The Infest question to be asked isi when do we want 
to link the modules of the linker together? To answer 
this question, we must bear in mind the important fact 
that linking modules together in some domain, whether 
statically o* dynamically, first requires mapping the 
modules into the relevant address space. 

Since each domain or future domain in the computing 
utility could, in the most general <4g|tt|f have its own 
address space, this suggests that mapping and consequent 
linking of the link d be done each time a domain 
is generated. Such a design woujid be^very expensive in 
comparison to the design where the linker was in the security 
kernel and was prelinked only once". 

We wi^uld leather like a design where the linker 
modules are linked together only once for the whole sys- 
tem just as in the case where the linker was in the 
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securlty kernel. However, such, a design requires that the 
linker be mapped into identical: addresses in the address 
space of each potential^ faultihg domain for the same 
snapped links to be »e«a*i»«H&tt£~i»^arll domains. This \. 
condition can actually be- fuliliil«0 became in all real 
systems that we can think of, eveifwhen each domain lias a 
private address space, all-address spaces contain some 
set of logical addresses in overlapping numerical ranges. 
Since -the linker is the first program needed in any domain, 
it is the firs^ program to be mapped into any domain 
address space. Hence we can, impose to map its modules 
into the same numerical logic J alJfc4dresses forjall domain 
address spaces ; (except the .jsm£dxi$y kernel address space 
of course) « This is .^G±iuM§ft.;^..|igu»e Jv Mapping of the 
linker into logical address spaces would still have to 
happen once for each logical address space created, but 
the costly operation of fabricating the snapped links 
could be performed only once. These snapped links will 
be valid in all domains if the ^ogi^eal mapping on which 
they are based is enforced in all ; domains . -We will now 
see bow, this can be done. ; 

The second question to be asked is: )b6w can we link 

^ "*"' ~ ■■■■■• 

the linker modules together? The -above discussion has 

actually divided the task of linking the linker modules 
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into two. We first must fabricate all necessary snapped 
links on the basis of some fictlve mapping* (ttf be 
decided upon) . We then must enforce thali mapping in each 
domain address space we create aliS we iiiit doOBuJiicate 
the snapped links based on that mapping to each new domain. 
We will now examine these two steps in distal 1. 

Fabricating the snapped link* is , as we already men- 
tioned, the task of a static linker. Sincre the snapped 
links must be fabricated lie fore any domain is created 
around the kernel domain, the static linlBer must do its 
job before or during system inifeiifl^ition^ *Before!* 
corresponds to the idea of a biftdet; "Daring" corresponds 
to that of a prelinker. The choiee between the two is 
the same as in the case of €h6 Security ketnel initializa- 
tion. As we have assumed the idea of the* prilinker for 
the security kernel, it ia all but hattirai to keep the 
same idea for the linker. The f lavor 6f the design is 
of course to use the security kernel prellnlcer a second 
time (with some variations perhaps) to pxelihk the dynamic 
linker. This saves the trouble of writing arid certifying 
another prelinker. Once the Security kernel is preiinked, 
and just before capabilities to use the prelinker are dis- 
carded, the initializer invokes the : prelinker again to 
prelink the future dynamic linker. Thr following para- 
graphs will discuss step by step the bperatibn of the 
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preliaker on the linker- fcaoaaee mm M*fet» of that 

optfttittfr x#m umm i?*a****M* that- m wma&a**ap of 

the kernel *Mf set- have. , ^ ;, 

t*„&*&&0&fm * W* Nf^^,^,****^^.^ ***** 

task, is- the fit****** H P^ : Wm^^^^ .^^^^ 
to the tatfM- of t*he .J***? **** tgp*olic na»e ie stored 
somewhere 1* the ori^e ca^^^jttw^liifc*. Since we 

want to gve^i^.atfl. link* ,iap^',,f*^| **» I ^ -ar ' ail 

nodale* of tip li»ke* jm ^v.-*^|^j : ^V t ^-^ e ^ ty 
kexj^.*etts««» asaee daring m&*m iM&U*li**tten~ She 
greiiafee* will, then- hft* the ,*HJ^;. f *CP |£w**r all 
syfifeolie IjW^ it «w*^.t#a«#Ia^ ; p^^^ ; f <2liR ~ 

nin? of all ffrttfty! 01 «» |i^8»^ «^#«*ibl« is the 
addreee apao*. , . 

the *•****.«*«* to be e^o^lifhed in ^relinking a 

link i*;ik^*e*r€ih\ifi tlie/fi-le.f!!^^".^^*^** 
object m****$m&m,&* <** Wf !*^ link be^ trans- 
late^ fh# »*t«*» ^ the "t^lf x ^pm^ r in th* elementary 
eavj£&VM^,.e£-. •¥**•* ^fc^^fPfJE*?*,;!* h*>wevi^ jfseetion- 
able, Any £sp#*$i*f guitar ia#»*» ..**» fSSl ** «W° rt 
.a, f lie? ffMlff #*i|«f »or»al e^wretion. But it ia not 
obvios* «lMt i» *il e*e>***ii» tttlU^M^f/ tlte file eyatem 
and the fttft .awfr, initialised and #vailaf*le at the tine 
the ^eiinke* i# rtm* If they ' **■> aearohing .of a target 
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object can be achieved by the FSM. If they are not, the 
target object must be initially brought into the address 
space of the security kernel from whatever memory device 
is used to load and start the system, otherwise it could 
not be accessed and identified by the prelinker. In the 
latter case, searching is reduced to a simple scanning 
of all objects in the address space and will succeed 
when the right symbolic name is found. This of course 
implies that any potential target object, i.e. the linker 
and any security kernel gate it calls, be in the address 
space of the kernel. 

Finally we have to worry about mapping. Once the 
target object of a link has been identified, a logical 
address must be obtained for it to build the link to it. 
The problem may seem trivial here since everything refer- 
enced by the linker and the linker itself is mapped in 
the current address space to start with. However, we 
must remember that whatever mapping we base the snapped 
links on will have to be enforced in all future domains. 
It may not be feasible or reasonable to map the linker 
and security kernel gates it calls into all address spaces 
at the addresses where they currently are in the kernel. 
In particular, we have mentioned that logical addresses in 
a domain are a form of capabilities for that domain. We 
have also mentioned that after initialization, the security 
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kernel will want to discard its own capabilities to ever 
again access the prelinker. «»4s iieei^ it lies *0 mmmp 
the prelinker from the- address epe^Hit*-«^re»tly ■• *eee . 
Along the sane lines «tf thou^fti, the li»«iwri# sliced in 
the initial kernel address apace -fee -^*HFp«iE|»seof pro- 
linking. But the linker is not peart of the security 
kernel. Hence the initialiser wifXafteo- ensjep^it after 
prelinking is completed. Consequently, '*#<•*% facing the 
following problem. All objects we ere in*e#eete# in are 
currently napped into the only vm&i^ x WBk&fc sp%e#V ; but 
this mapping is t em p o r ar y and the &i&ute se^pine? to be 
used in all domain* other than th* security- kernel domain 
may be entirely different as r e pr e sent ed l^ ; -fig*iS* $.'■ 
This future mapping is of coursw t$m '^toeUxm mapping we 
discussed earlier. Determining the fietive mapping is 
thus done by the prelinker by assigning the target object 
of eacli link it translates a -IbfieeJ r; aildre^- e^tafcl* for 
all future domains. 

Let ua how conclude the above discussion by deaerib- 
.ing .the -mapping function of ^y;pr#lfh*er»- figure 4 
illustrates this function, the "prelin&er -"***•• and pro- 
gressively builds up two tables. *fci v f^^ 
table contains a set of entries of the form (logical 
address - unique identifier J . ^ch each entry defines 
the future logical address of the uniquely identified 
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object. Each time the prelinker snaps a link to a target 
object in the linker sot already assigned a liatlte log- 
ical address, it generates a suitable fictive address 
and adds one entry to the table for that object. The 
snapped links table contains snapped links already fabri- 
cated by the prelinker. Such snapped links of course will 
be meaningful in all domains as they are based on the 
fictive mapping which will be enforced in all domain*. 
Once all logical links issued from the linker are fabri- 
cated, the pselinfcer task is completed. The- security 
kernel can thus discard its own capabilities for the 
prelinker and ths linker by dii*li*cating their addresses 
in the current address space, ©wry the' two fables- built, 
by the prelinker remain in the address space of the 
security kernel. They will be used to drive the initiali- 
zation of each subsequently created domain. 

We have just described how the snapped links of 
the linker could be generated. It remains to be demon- 
strated how the fictive mapping on which they are based 
can be enforced in each new domain. Such a task is part 
of each domain initialisation . It i» straightforward. 
Each time the security kernel exmmtMa a new domain, it 
uses the fictive mapping table to drive the FSM and have 
it enforce the mapping in the new domain. Each entry of 
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the table is interpreted as a request from the new domain 
to search the file system fbr tWrtbjisWIiffquety iden- 
tified by the entry and to map it into the specified" f ic- 
tive logical address. After having done so for all 
entries, the fictive logical ' c &a&*&k*ktt «rer "actual valid 
logical addresses for th# he^ ^olaaih,. Their "the security 
Kernel map* a copy of tfher stiap^ptei li^cr NSaMe" into the 
new- domain address space . -: ThlW wl 11 f iftal ly enable the 
linker to properly operate in tiii n«W dttfoain by'tising 
the snapped links based on the iioW real mapping for that 
'domain. '"■'"■■ ;t "' i 

What we have achieved is providing each domain with 
an operational linker; 1*W. a prefinfeeH linker^ The 
first section of this chapter 5 descril&d fcW the security 
kernel could be initialized without" the : nelp*6f the dy- 
namic linker. The current selct ion ha* ^eicribed how the 
dynamic linker could in turn be initialized in much the 
same way. A fictive mapping of thsiittkfer and some 
security kernel gates had to be genirated " during system 
initialization and must be enf orced by the a *SM indepen- 
dently for each domain created dtirlni system operation. 
Each such domain then sees the linker and relevant security 
kernel gates in its logical addresi ipace. In Addition, 
each domain has a copy of the snapped links required by 
the linker to operate. Link faults can now Safely occur 
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xa such domains* jfu* will be the topic ia the next 

4. Xtiafc fault .hwMMng. 

So far. we have ahown how to, imitialiee * eecarity 
kernel without the heJ<p of * dynamic linker, «e then 
bay© shown how the security kernel can .in, turn imitielise 
.a linker in each domain it create*, xt jwimi to fee 
demonstrated bow the operational .liailcer. we aw Mve in 
each domain can handle link fault* without the privileges 
it would hawe if it Here in the security kernel, domain. 
As long as it waa part of the security kernel, the linker 
had all the «apabiliti#s it wanted to Access faulting 
domain objects, target <dcmaia .abject*,, and any object in 
general. He now will show that the constrained privileges 
available tP the linker in the faulting domain are still 
sufficient .to,, giaurantee proper operaiife. 

The first problem we will now discuss is that of 
invoking the linker in the f«ulti^ ? domain. Suppose that 
an object being executed is seme domain ceases a link 
fault by attempting to reference another em ject through 
a untranslated symbolic link, able Jink fault is an 
event .recognised by the hardware of td»a....aystep l . as. a 
result of the event, control most be given to the linker. 
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Some faults-access violations for instance-are very sensi- 
tive events and must be hanMed by i-ne security kernel. 
Since the processor recognizes* har dwafcir ■ events themselves , 
but may not know about their nature or 1 ihelr sensitivity, 
it is frequently necessary that all faults 1 be sorted by 
the security kernel before being' pasirelif t© any .other 
domain for handling. Consequently 'V oh a^Mn* fault, the 
first program to be invoked Is the se^clirlW Jcerfcel . It 
in turn has to Invoke the Irhkerih ^» l *iul^iTig domain* 
Such action may seem straightforward. "i^i^security^ 
kernel could just call a gate into this' faulting domain 
and that gate could in turn ca^l^tie 1 lfn^e¥l «ow«ver , 
if we want to be absolutely general, x ou# design must fit 
systems which support a very large "iSumttlr of domaiits. in 
that case, since any domain is a pdtiiilxai'faBtitihg domain, 
the security kernel needs to know abotit J a s gate ihfcd each 
domain. But since domains ahd gatls caii'be'fere4ted 
and destroyed at will during syslia op^ratibnv it is 
impossible to pre link the i' kernel ; tb J a^%f^~lnto : ' ; ea'ch' 
domain at system initialisation tlAe. Mttskde we must 
find some means to enter the 'Tau^^ng^^UiBiiin^^tt^iit 
knowing about any gate into it. i&^'we ^81: 's^fflaehow 
invoke the linker in that domain^ '"Ifeuiy" -iai&erent'- ; 
solutions can be proposed to Hiese ' : 'j>£$kfa.&B& depending 
on the details of a particular syiiiif ^"#sWexal, 
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a computing utility always has a mechanism to transfer 
control fro® the security kernel to another domain without 
knowing anything; shout thatt domain. 

lite wili o«fly mention on* passible solution for the 
sake of Qara$a«*tejxess, but we dp not claim authorship for 
it and we insist on the fact that different systems may 
require different mechanisms. Since the security kernel 
maintain® and enforces protection, it usually has the 
power to dynamically and temporarily force access to any 
object in any domain if necessary. For instance, on 
many machines** the supervisor can reset the privileged 
mode hit at will. Qonseguently , even though the linker 
is not a gate* the security kernel can force control to 
jump to the linker in the middle of a faulting domain. 
This solves the problem of entering the domain but we 
still have to know where the linker is in that domain to 
jump to it. For that purpose we can simply store the 
logical address of the linker at some conventional address 
in the faulting domain. Hence, on a link fault, the 
security kmrnei analyses the machine status to determine 
the faulting domain. It then looks up the logical 
address of the linker for that domain at the conventional 
addresa and forces the control to jump to the linker in 
the faulting domain. Initialisation of the conventional 
location is part of the domain creation operation. 
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This design has a side advantage. By changing the 
address of the linker in the conventional location, the 
subject executing in the faulting domain can define any 
other program to be its linker. It just has to pre link 
its own linker with the standard linker" prior to changing 
the content of the conventional object. 

Having described how the linker is invoked in a link 
fault, our second topic will be to demonstrate that the 
symbolic link which caused the fault can be snapped with 
only the capabilities of the faulting domain. In the 
earlier description of the operation of the linker, we 
identified three steps in the snapping of a link: 

- Identification of the symbolic name of the link 

- Search for and mapping of the target object 
corresponding to that name 

- Translation of the symbolic link into a snapped 
link based on the previous mapping. 

The first and third steps require exclusively access to 
the faulting domain because that is where the symbolic 
link and the mapped link belong. The target object and 
the target domain do not contain any information about 
links directed towards them. The linker has access to 
the faulting domain and can thus handle steps one and 
three. If the target domain is different from the 
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faulting domain, the second step sight require information 
embedded in the target domain. However, searching and 
mapping are actually performed by the FSM in the security 
kernel. The security kernel can access information about 
any target object. Thus the linker just calls the FSM 
through a gate into the kernel. The FSM then searches 
for the target object, decides whether the faulting 
domain has the right to know about it, eventually maps it 
into the faulting address space and returns a capability, 
i.e. the logical address of the target object^ to the linker 
in the faulting domain. He will see in the next chapter 
that in some systems, complementary information about the 
target object must nevertheless be extracted from the 
target domain. It will be shown then how this can be done. 

We finally discuss the third problem, namely return- 
ing control from the linker to the faulting object 
The goal is that the action of the dynamic linker be 
entirely transparent to the faulting object. The only 
noticeable difference in the environment is the now 
translated link. Apart from this, the faulting objects 
expects to find everything unchanged. 

The machine registers must reflect the machine status 
just before the hardware fault occurred. For this purpose 
the linker needs to restore the status of the machine. 
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When the linker was invoked it received a copy of the 
status of the machine to "firid^out what caused the fault. 
Restoring this status in the machine registers must be an 
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atomic operation to guarantee consistency of the status 
as a whole. It would be a prptee1:ion vj^a^l^h to allow 
any domain other than the security kernel to restore the 
status of the machine. Restoring the machine status is 
done by copying data out of some object" into the machine 
registers. If any domain could perform such an operation 
it could set the machine status to a pattern reflecting 
a subject in some other domain. Ttiis wouloT be equivalent 
to jumping right in the middle of t domain and by-passing 
the entire protection mechanism." ! Hence restoring €he 



machine status requires security kernel privileges which 
the linker does not have . Thje "drily solution is to have 
the linker call the security kernel. A gate must be 
installed in the security kernel for ^that Tpurlpose '." The 
gate will examine the machine status '""it is asked to . 
restore. If and when properly validated, the machine 
status is restored and control jump* "back* to where the 
fault occurred in the faulting Object,? Validation of the 
machine status to be restored must determine what domain 
is defined by the machine status, ahd verify that that 
domain is the faulting domain* Again, the latter mech- 
aniSm described is one among several possible designs 
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pf a feature of general interest which any computing 
utility supports under some form. In many cases, the 
single fact of trying to restore the machine status from 
the faulting domain causes control to switch to privileged 
mode in the supervisor. The restore instruction itself is 
the return gate . Again we do not claim authorship for 
the mechanisms just described. 

5. Cross domain problems 

The first two sections of this chapter have discussed 
the initialisation of the security kernel and of the 
dynamic linker. The previous section has then discussed 
the handling of link faults by the operational linker. 
The design may therefore seem complete. It is not. We 
will now discuss a hidden problem which we have only 
indirectly approached end carefully avoided mentioning 
so far. The problem is directly related to the multi- 
domain aspect of the computing utility. It is a problem 
of general interest which exists in any multi-domain 
computing utility. Our research came across it and 
uncovered it for the first time. Me believe that it may 
have been solved in particular cases almost by accident. 
In general f it has been ignored. Hence we will propose 
a general solution for it. 
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The linker is invoked on a link fault and completes 
its task by asking the security kernel to restore the 
machine status. It is not properly speaking called by 
the faulting object and does not properly return to that 
Object. It takes no "input" or "output" arguments. 
Instead the objects it receives to work on are defined 
by the machine status automatically saved by the security 
kernel and the result of its computation is a snapped link 
The question we will now discuss is where does the linker 
store the snapped link so that the faulting object can 
later retrieve it? Or in other words, what is the 
nature of a logical link? 

In a computing utility where information sharing is 
a fundamental objective, special care must be taken to 
drganize the sharing of program modules. In order to 
operate, a program requires working storage to store and 
retrieve data. One usually distinguishes three kinds of 
working storage: in a PL/1 environment, these classes 
or types are known as external, internal static and 
automatic storage. Data modules or data objects as we 
referred to them in the thesis are examples of external 
storage. Many programs can refer to a particular piece 
of external storage. That piece is external to each pro- 
gram and shared by all. External storage can be created 
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or destroyed at any tine and j oan .ex|.st. ; as long as desired. 
Automatic storage on the other hand belongs to a given 
program, is not shared, is created ;3gtpiB the jprogram is 
invoked and disappears when ac^on^ resulting from that 
invocation terminates. ., A stack frame in. an Algol machine 
is a typicai example of automatic, storage.. Internal 
static storage shares features of au|o«a.tic and O.JL. 
external storage.. Like automi|tic^,stpraj|e.,it is private 
to one program and not sha^a^lf^ L|^e a |^ernal storage, 
its life time can be more than just one ^vocation of the 
program. Internal static storage tag. .definition is allocated 
to a program when that program iQ/J&wpt&fbgpK the first 
time in. a domain* and is ^m^ro^^--,€m^^^ : ,i^,,4^maJkn is 
destroyed . in other words iiite^rnal, .*taj:ic storage con- 
tinues to exist between invocations ojE, ^ program, as long 
as the domain which contains? it exists. Going back to the 
problem of information s ha ri n g in a, oaefggt^ng, utility, it 
is clear that procedure code (provided it is pure) can be 
shared by different subjects in d^ffe^f^ domains, 
similarily, external storage, can, be shared, perhaps with 
some precaution*! sharing externai, atorage^allow^ sharing 
data. However, it may be desirable ..not. ,..*£ . .shares internal 
static, and it is certainly desirable no*, t© share auto- 
matic storage. Let us consider the case of internal 
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static storage* Sharing internal static -..storage may lead 
to conflicts since subjects in different^ domains may carry 
on different computations with the same procedure. Thus 
mutual protection and independence of desmans will in 
such cases require different statist storage j .areas to be 
allocated in each domain where, a l pjeocediwrev is currently 
used. We will assume such a case in the following dis- 
cussion and will propose a design whishe allocates static 
storage on a per domain, has is* It should now be clear 
that a snapped link is a typical example of an internal 
static information item* It is meaningful only in a 
given domain during, the existence of that domain* Hence 
in each domain where somer procedure objects is, currently 
used* an instance of o»ch link issued from the procedure 
is stored in the static storage; area assigned to that 
procedure in that domain. The set of -all links issued 
from a procedure is referred to as the linkage section 
of the procedure* Thus, an instance? of dfche* linkage 
section of a procedure exists in each static storage 
area assigned to that procedure in theedomeias where it 
is currently used. Both the linker and the procedure can 
retreive the appropriate linkage < seetioA ; ajeeerding to some 
system wide convention which is left to the discretion 
of the designers of the system. 
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The hidden problem we mentioned earlier is that of 
deciding how ataxic storage should be allocated when a 
procedure is about to be used for the-'- first 'time by some 
subject in aome domain. Often this teak ia left to the 
dynastic linker. Such awkward design results in a major 
protection violation instance. We will now discuss why 
and propose a correct design. 

Clearly we do not want to allocate static storage for 
all programs executable in a given domain when we initialize 
that domain: it ia impossible to scan the whole file system 
to. find all procedures executable' in vtheedomain and-- allo- 
cate static storage for them; it : ±au simply impossible to 
know in- advance about all procedures executable in the 
domain because of- the- dynamic ■ aspect off the; file system. 
On the other hand we want to be certain that when a pro- 
gram is invoked for the first time in a gi van domain, 
static storage' .ia already allocated- fo*-= its •linknge- sec- 
tion so that the executing subject can look it up when it 
needs to follow a link to some external abject. 

The firet solution which comes to the mint* is to allocate 
the space when the object is invoked fox the first time. 
On the assumption th*t all objects axe invoked by symbolic 
names and given that all symbolic links are handled by the 
linker, we conclude that the linker Should allocate static 
storage when it discovers it is snapping a link to a tar- 
get object which has not yet any static storage in the 
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target domain. Although this seems to be a clean solution, 
it violates protection, Indea#/+*f a su*g«ct could get the 
logical address of a target object^ by guessing it or by 
appropriate calls to the security kernel , it might call 
that object directly by logical , address va«d J not by sym- 
bolic name. In doing so, it will byr®«ps the linker and 
will end up executing an object which has -■■•not been pro- 
vided with static storage; this i# likely to T terminate 
the life of the subject. Protection; wi#e; i$c is perfectly 
legal as long as the subject hurts only itself in the 
current domain. But if the t*Fge$ i©bj*^ the subject was 
calling is a gate into another • domain,,; by-passing the 
linker could cause damage to tb#ttl^g^?d4^pain by not 
initializing some static storage as expected. This of 
course is a violation of the - prota#ti#*i ©f the other 
domain. In addition, having ,the ; linker in the faulting 
domain allocate storage in the target domain could be 
very hard to achieve. 

The second solution which comes to the mind and 
seems perhaps easier to implement is t© make static stor- 
age allocation a function of the FSH. Since using a pro- 
cedure in a domain requires mapping it into the address 
space of that domain, the FSM is guaranteed to be invoked 
for any procedure each time that procedure is used in a 
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dif f erent domain. Thua the FSI§ could at that time allocate 
static storage to that procedure in "tho appropriate domain. 
The FSM is more likely than the linker to have the capa- 
bilities; to do so.. However this dawaifit also- violate* pro- 
tection. Since the linker invokes the "UN, by symbolically 
referencing without even invoking all fates into a domain B, 
a domain A could create a mass of link faults causing static 
storage to he allocated to each #•** into domain B. Such 
mass allocation could overflow the storage available in 
domain B thereby violating its protection since it would 
have been triggered by domain A. 

As our research naturally came across the question 
of static storage allocation, the above' problem was uncov- 
ered. Obviously another solution had to be proposed 
which would solve the protection problem. In addition, it 
was felt that static storage allocation did not functionally 
belong to the dynamic linker to start with., Thus a correct 
design, but also a much cleaner and mere efficient design 
is proposed hereafter, It is based on the fact that static 
storage allocation is triggered by the domain itself where 
it must be allocated. Thus no protection violation is 
possible. 

when execution of a procedure object starts, the sub- 
ject must, according to the system convention already men- 
tioned, retrieve the linkage section of the object in the 
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current domain. We suggest that this search generate a 
hardware internal statie storage rau^ ll^ fault) when 
and if it fails. Thi* *«S fattlt s%biii# feM hanldied by the 
system in a manner very similar to a link fault. It 
should be passed to the faulting domain. Awa^tysfs of the 
machine status would te 11' whieW object r«qu£re«r it ati c 
storage to be allocated. Static i ^oi?ige r wdtild ; be 1 created 
in the faulting domain for t§f«€ ; -f a^l&iflljjNSb jecfcl After the 
machine status is restorers, the stibf#c^ l Wu^#1iucces*fully 
retry the search. Of course j4^'-li^fi'^Sak "C&k&t&t %ad to 
be prelinkedV %he static storage alloca*©r r i*ust have its 
statie storage allocated at domain iaillial;^a*feioh to Be 
operational. ^'r^ivj.r ^:.:v 

The design we have j^ust proposed %yarmntees the pro- 
tection of all doraai&e -oeoeuee 'WfW£fW%ftt£ii^^logat&on 
is made independent of- adynamic M^ifcdt&bg 1 '. : ~ Hence* J al location 
is no itore triggered .by the 5 dii«io J iit%oif o¥? # r%ndo» untrus- 
ted object , but by : - the execution or^ thl# ©Inject itself 
which needs static storage. ■^ / 'Thlft^<ii4^ig«"%teelkl■' ; lro^B■ the 
simple fact that no object, and p%r^^^Ia*ly no gate into 
any domain, can depend en a eal lei* iH^^tk&'^o ^perform-' any 
task in generals, static ¥tor#g* ! allooa^dW in particular . 
- Given that links arfe per doma in static items, it is 
now clear why the security kernel must communicate a copy 
of the linker links independently to each domain it 
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creates. This copy As Aastalled Aa.-the^sfcafcAo *$°**f e 
area of the lAnfcar An that domain- 

6. Summary 

itoAs chapter baa attempted to fctwnfc^ oomplete 
design of a dynamic lAnker running sOufemAde- the; security 
kernel of a computing utAAAty. Four wain problems have 
been distinguished, It baa bean demonstrated f Are* that 
the security kernel could be .made operational without the 
help of a dynamic, linker. It ha* ,heen shown that the 
dynamic lAnker oould be made : «^dM>l3^ ri^^^^: 4s»«^^»- 
while being prelinked only once. It baa than- been 
explained how the linker handles link feui**» finally* the 
hidden although f undaraantal problem eC /*l?»*Ao storage 
allocation i» a muitidomaAa eysteev was *MMm»9*&* a^As 
concludes the presenfcafeAon of the complete design. The 
following: chapter will illustrate the use of the computing 
utility model and $he princApl«» osf the design by Adeati- 
fying the component* of the model to thoem of a real world 
system m^ applying the design to that system. Concluding 
remarks on the- actual Aim^Aemeo^aJtAonr *»i%A oo^srAnoe the 
reader of thet feasibAAA*y *»** usefulness of the design. 
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IV. Implementation 
1 . General 

In developing our thesis we have first discussed a 
computing utility model which enabled us to give a formal 
description of the operation of a dynamic linker. In a 
second stage we have presented and discussed in terms of the 
the model the general design features of a computing util- 
ity where the dynamic linker is executed outside the 
security kernel domain. We will now build up the third 
level of the thesis. This level consists in demonstra- 
ting the feasibility of the proposed design by describing 
and analyzing the details of its implementation on a real 
world computing utility. 

The Multics system has been chosen as a test case for 
the implementation. The Multics system (15-18) is a com- 
mercial computing utility developed jointly by the 
Massachusetts Institute of Technology and Honeywell Infor- 
mation Systens, Inc. It is supported by the Honeywell 6180 
computer system. It implements a powerful virtual memory 
time sharing system with extensive information sharing 
facilities. In addition to being easily available for 
this research, Multics was a very interesting test case 
for our design. 

Firstly, Multics was designed with protection of 
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inforraation as an initial objective. Protection has influ- 
enced almost all of its design features. Protection 
mechanisms are embedded in most of the functions available 
on Multics. Even the hardware of the 6180 processor was 
designed to support the concept of domain (15) . 

Secondly, a recent project has been launched with the 
objective of defining and auditing the security kernel of 
Multics to certify the correctness of the protection 
mechanism. Since the dynamic linker of Multics was 
initially designed to be executed in the security kernel 
environment, the present research matched exactly the 
objectives of the certification project. 

Finally, the protection mechanism of Multics matches 
very closely the domain protection model as described 
earlier. Hence there is a direct parallel between the 
description of the domain based design and its implemen- 
tation. 

We will divide the discussion of the implementation 
into four parts. The following two sections will at the 
same time briefly describe the general design features of 
Multics and match the real system components with the con- 
cepts of the computing utility model described earlier. 
The next section will then talk about a dynamic linking 
specification on Multics to familiarize the reader with 
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the nature of the functions which the dynamic linker is 
expected to support. The remaining sections will present 
the reader with a discussion of the implementation of the 
dynamic linker. Emphasis will be put on the discussion 
of selected specific problems i encountered! by \ thjto imple- 
mentation. We do not claim tliat. t^4Wf»*4«s4 -Aj> be discussed 
constitute an exhaustive list of all problems which the 

; ; ! i ? , ' 

imp lement at ion faced . Out oT tHi" ofS0fS^T If il o f pr ob- 
lems encountered during the implementation, we shave 
carefully selected specific problems which wis believe are 
instances of more general prc>blem» -that -a»y designer is 

! 1 r : . 

bound to face on any computing utility? ttaiSaif some form or 
another. 



2 . Information Protection in Multics 

The equivalent of a domaia itt-JteletAeg -.-■■jBs- a ring (15, 
18) . Rings can be Viewed as a set of domains frith a 
linearly nested ordering of privileges. The set of capa- 
bilities of any given ring is a, aubse^ of t^e capabilities 
in the next most privileged rihgV aS :J ripris«*4eirin 
figure 5. The 6180 hardware processor supports up to 
eight rings for each user. The eight rings are numbered 
from to 7 by decreasing order of privileges. Because 
every ring has at least the capabilities of the next 
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Figure 5: Multics protection rings, 
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higher numbered ring the concept of gate exists only in 
this dcfwnward direction of crbis^tinf * 'ci'lls ~. :i W sub j ect 
executing In" xlng ;: n ? ftustf- ask «htfry permission to a gate 
if h* wants to obtain - the r efcrtra cap^&i'i'itiis of ring in 
<m smaller^ thafr n) I 6n the oti&r' l handV'a ; ' Inject execu- 
ting in- ring ft 'i and ' willing to 7 raove f Wring ft ( again in 
smaller" than- n} can freely do* 'io, :x ttA*f£ea "'Of a gate 
into ring ft £ or ring ft is 3 irrelevant. a ^'- J '- m- -■•■'- -• 

All ftsers ^presumably) fcrui* 1 "fche w se&ir ity^ kernel more 
than their own programs which 1 ^^ ina^contain"^*^ capable of 
causing trouble. In turn they probably trust their own 
programs more than either user* §t?p*8|ra#§ totals relative 
or€erihg of s pro^aaii*:an Be suferlrap^iea^td^tifie relative 
ordering of^rifcg*;- Since the-s«ciriiy^fce§&et l ir ; by : '- 
nature the t^st w trustw6rthy l set of ^p^ograraai^ it is designed 
to be executed in fing-O'. °Blt€ J it u aiSil^ Be isolated in 
this ring from ever^h£ng d e«ii' ! iiityi eMI^fime'nt. Hence 
the rest of the sopervisor ^ft6uld*b^ r§jec^ed ? t6 f ring 1. 
Perhaps ft pr«g*ams "under deveiapTni^t ^F ^§sl ri sen W€ive pro- 
grams 0f r th6 sup^rvisBr 'should be-iiii^aiie^^in ring 2. 
This idea is currently being HtJuHed^^eiei ci pro|famsr 
cbmmattdi; compile** and ^thdr a <^itf l1 ifreciiiy x ifelate^d to 
the act^ris of Risers caif "tie^dStfofcita ffi rfnfa°3; 4 and 5. 
The normal dale is ring 4. ThW T ii$3§! && £ user 'to 1 Execute 
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protected subsystems in ring 3 on the aasta^ption that 
everything in rings below 3 is trusted and tfiii not sub- 
vert the subsystem in ring 3. A user can also test uh- 
trusted programs in ring 5. Kings 6 and 7 are absolutely 
virgin: no function of the operating system is available 
there. They initially have no capabilities for any gate 
into lower tings. Hence a user may use these few© rings 
to install any two-ring system he wants and keep it en- 
tirely within his control. 

3. Information Storage in Multics 

The Multics equivalent of a subject is a process* A 
process is defined by a site of execution and a logical 
address space. Each process has its own address space. 
A process is the entity representing a user in the machine. 

The address space seen by a user in a two-dimensional 
virtual memory of very large capacity (15). Along one 
dimension the memory is partitioned into segments addressed 
by their order number. Along the other dimension, it is 
addressed by word. Hence the logical address of an object 
in this virtual memory is of the form (s,w) where s is a 
segment number and w a word number in that segment. The 
format of such references limits the si?e, of the virtual 
memory to 256 K segments X 256 K words. 
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Multics file system is a tree- structured hierarchy of 
catalogs. Catalogs are called directories. The leaves 
of the tree are called segments. A segment is the equiv- 
alent of a collection of objects in our model. An atomic 
object is an entry in a segment. Directories are also 
atomic objects.' The unique identifier of a directory is 
the tree-name of the directory. The unique identifier of 
a segment is the tree name of the parent directory concat- 
enated with the symbolic name of the segment. Directories 
and segments of the file system are of course mapped into 
segments of the virtual memory when they are used. Such 
mapping is supported by the FSM. 

The security kernel of the operating system is 
shared by all users. Since it is the very first thing 
which has to be operational in any process, it is the 
first thing to be mapped into any process address space. 
Hence the security kernel always occupies the same loca- 
tions of the virtual memory of each process. Furthermore, 
all rings in a process share the same address space. 

4. Dynamic linking in Multics 

The previous two sections have established a parallel 
between the Multics system and the computing utility model 
of the thesis. Our second step towards the discussion of 
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the implementation will be the statement of dynamic link- 
ing specifications in MultiCs. 

The Multics system supports various high-level 
languages but wis initially designed to- support PL/1. 
Most of the system programs of Multics are written in 
PL/1. As the address space of a Multics process is two- 
dimensional it was both easy and desirable to have a two- 
dimensional name space for PL/1 symbolic names. An object 
symb o lic name or entry name is of the form segname$entryname 
where segnarae is the symbolic name of th# seg- 
ment containing the entry and entryname is the symbolic 
name of the word offset where the entry is located in 
the segment* 

Given a source program (or source segment) any com- 
piler generates an object program (or object segment) 
which contains three sections as described in figure 6. 
The last section contains the pure executable code of the 
program. The definition section contains on one hand the 
list of entry names and word offsets of all entries in the 
object segment. On the other hand it contains the list of 
all names of entries into external object segments which 
this object segment may reference. Finally there is the 
virgin linkage section. We insist on the word virgin 
which is used to distinguish the present type of linkage 
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Figure 6: Multics object segments 
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section from a non virgin linkage section which will be 
derived from the virgin one and is in the static storage 
area as described in the thesis. The virgin linkage sec- 
tion always remains virgin and is sharable . For each ex- 
ternal object referenced in the source program, a link is 
inserted in the virgin linkage section. 

A link is a triple (s,w,f). (b,w) is a logical 
address as defined earlier and f is a flag. In a symbolic 
link, the flag is always a bit pattern indicating that 

(s,w) is invalid. Attempting Jtjo use (s,w) as such will 
cause a link fault. At this point j(s,w) somehow points 
to the symbolic name associated with the link, in the 
definition- section and not to the target object o€ the 
link. When the object segment is ffLrst executed in a 
ring, static storage is allocated fpr it in that ring. 
The virgin linkage section is copied into the static stor- 
age area yielding a non-virgin linkage section. The 
address of the non-virgin linkage section is stored in a 
conventional location where an executing process can 
always retrieve it when it uses the object segment. When 
execution encounters a reference to an external object, 
the linkage section address is used to look up the corre- 
sponding link. This triggers the hardware fault since 

(f) is set. As a result of it, the linker will snap the 
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link by replacing the invalid (s,w) by the! valid address 
of the object corresponding to the entry name j*fitlsh 
caused the fault. The fault flag (f) will/be turned off 
to indicate the validity of (s,w). We now j have a snappejd 
link to the target entry. If and when ^hefsame link is 
used again i$ the future by the same ussier process, no 



more linkage fault will be taken. To Clarify the above 

disc"ulii6h, the situation is pictured JTn f JtSuBeTTT "** """■"""' 

■'■' j ^' ■--] .*-.-— ^■'„,^^r:= :,jp«-n -■■•■ •■•• 

In view ; of the above, description , «we ! can, now present 
a simplified basic functional -block diagram—of- -the 
dynamic linker (see figure fc) . On a link fault caused by 
object A (see figure 7) ^the-dyiftaml 8 "* linking driver is 
invoked. It analyzes the machine status to determine 
which link caused the r linkage^ fault! * A By following the 
pointer (s,w) currently in the symbolic li&k, the' linker 
finds the symbolic, name B $ b correpsonding to that link 
in the definition section of the faulting dbject A. It 
then passes name B to the segment search driver. The 
segment search driver trd.es a set of sea^JPrlilis *Ta"! rec- 
tory treenames) on the FSM until the FS|i f^nds B in one 
of the directories. The FSM then maps^B ifit6 the address 
space of the faulting process and returns the segment 
number s of "b to the searbfcr drive? which iknEuxTTTeTQtn« 
it to the linking driver. 4 The linking d^i^erj then passes 
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Flgure 7: Dynamic Unking 
on Multics 
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Flgure 8: Functional diagram of the 
Multics dynamic linker. 
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the segment number s and the name b to the entry search 
driver. This one scans the defi^tjion secti-on of segment 
numbered s (i.e. B) until it finds the name b. It then 
returns the offset w of bin B to the linking driver. 
The dynamic linking driver finally replaces the address 
(s,w) in the symbolic: link by the addresser Ts,w) of B $b 
and turns off the flag (f) to sake the link a snapped 
link. The machine status .-caft then be restored and 
execution can proceed. 

We do insist on the fact that the above description 
is a simplified strictly functional definition of the 
linker. In no way should it be assamed that the linker 
contains only three modules and that linking happens as 
naturally as we described it. In the course of this 
chapter we will progressively complicate the description 
we have just given and discuss the problems encountered 
by the implementation* This section concludes the 
descriptive part of "the chapter. We will now apply our 
design to Multics and present selected aspects of the 
implementation. 

5. Initialization 

In this first section about the implementation of 
the design, we will outline how the security kernel and 
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the linker are initialized. This outline will be brief 
because no particular problem was encountered. The im- 
plementation of the design was relatively straightforward. 

The Multics system is initialized by a dedicated 
initializer process. All modules of the security kernel 
are loaded into the system from a generation tape . 
Immediately after the loading, the virtual memory address- 
ing mechanism is initialized so that the initializer pro- 
cess sees a regular virtual memory with the restriction 
that the capacity of that virtual memory is temporarily 
constrained to that of the real memory. A prelinker is 
then invoked to link together all modules of the security 
kernel which are read in from the tape. After the pre- 
linker is run, miscellaneous initialization tasks are 
performed. When the security kernel is entirely opera- 
tional, the prelinker, as well as other initialization 
programs are unmapped and thrown out of the addressable 
space. We have described this mechanism for the sake of 
completeness. However it existed before we implemented 
our design. We used it as a basis for our implementation. 

We now turn our attention to the initialization of 
the linker. Since the security kernel is initialized by 
a prelinker, it is all but natural to use the same pre- 
linker a second time to initialize the linker. Actually 
the implementation uses a hybrid technique involving both 
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a binder and a prelinker. Multics provides its users with 
a binder of which the goal is to take several object seg- 
ments and to marge them into one which ha* only one text 
section, one definition section and one virgin linkage 
section. Of course any link between the original dis- 
tinct object segments submitted to the binder are directly 
translated into relative of f set* Id. thin the resulting bound 
object segment. Hie binder was used to bind together the 
modules of the linker, i.e. the modules inside the main 
box of figure 8. Consequently the only link* issued from the 
bound linker, which the binder could not translate are 
links to the FSM and links to external data bases. Notice 
that figure 8 shows only one link to the FSM. I* reality 
there are several such links, ft* we stfid earlier figure 8 
is only a simplified functional diagram. To be more 
accurate too, the links to the FSi* aMe 1 actually links to 
ring gates since the FSM is in the security kernel and 
is accessible only through these gates. Jtlsty the links 
to external data bases are not repre*ehted in figure 8. 
The external data bases are error code tables attd system 
data tables. They are used by the linker but are not 
really part of it and do certainly not beldfig in its 
functional diagram. 

The task of the prelinker is thus to snip the links 
from the bound linker to the external data bases and to 
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the security kernel gates. The operation of the prelinker 
matches exactly that described in the general case. Since 
the prelxnker does not know about any file system, (even 
though the bound linker, the i external data bases and the 
security kernel gates are catalogued in the file system 
and stored on secondary memory) a copy of each module must 
be loaded into the initializer address Jpace from the 
system generation tape. The bound linker is loaded with 
attributes such that it does hot get prelinked as a module 
of the kernel. Instead when the kernel is initialized 
and just before it throws the prelinker out of its address 
space, it invokes the prelinker a second time to prelink 
the bound linker. The prelinker builds a rictive mapping 
table and a snapped links table as stated £h the general 
design. In the particular case > of '""iiul tics 7 the snapped 
links table is simply a copy of the virgin linkage section 
of the bound linker where all syraoblic links are replaced 
by snapped links reflecting the fictive i "mapping. The 
fictive mapping table is a little more 'interesting. Since 
there is only one address space per process common to all 
rings instead of one per process and per ring, the reader 
may wonder why a fictive mapping of the linker, the data 
bases and security kernel gates is necessary. Couldn't 
they just stay where they are? The answer is "negative 
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because of the peculiar way the security kernel is mapped 
into each process address space. It is a convention that 
all segments which are part of the security kernel during 
regular operation are mapped into the lowest segment 
numbers of each process address space. Hence all lowest 
segment numbers are reserved for the kernel and constitute 
some sort of private address space. Mo such segment 
number is ever used outside the kernel. Hence, even 
though the linker, the external data bases and the security 
kernel gates are in the address space during initialization, 
they must be remapped into higher segment numbers for the 
higher numbered rings. That fictive mapping will be valid 
for all rings (1 to 7) of all processes. To summarize the 
problem, although the address space of a process is common 
to all rings, a fictive mapping must be installed by the 
prelinker because some specific rule cuts a piece out of 
the process address space and turns it into what may be 
regarded as a private kernel address space. If this rule 
did not exist, clearly, the initial mapping could be 
kept and be the final real mapping . Af tes .the two tables 
are generated, the security kernel throws away its capa- 
bilities to access the prelinker, the linker and the ex- 
ternal data bases by simply deallocating their current 
segment numbers. Remember that the linker and the data 
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bases are still stored in the file system on secondary 
memory, so that the system can retrieve them there later 
on when they will be needed. Of course the two tables 
built by the prelinker may not be thrown away. Since 
they will be used throughout the life of the system each 
time a ring is created, they must remain permanently in 
the address space of the kernel. 

We finally come to discussing the task of enforcing 
the fictive mapping. This task is also straightforward 
and identical to the general design. In order to operate 
correctly, Multics object segments need a static storage 
area and an automatic storage area. Automatic storage 
is allocated in a special segment called the stack. This 
segment is used as an Algol call stack. Static storage 
is allocated in a special segment called the combined 
linkage segment (els) . There exists one stack and one 
els per ring and per process. There exists a system 
wide convention stating that the stack of a given ring 
always occupies the same segment number in the address 
space of any process. This enables any process to find 
the right stack in the right ring. Each stack header 
contains (conventional) the address of the els for the 
same ring. This enables any process to retrieve the 
right els for the right ring. Given these two conven- 
tions, it is clear that no process will ever be able to 
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touch its els in a ring before it touches its stack in 
that ring. Hence the convention is that when the process 
uses its stack segment number for the first time, a hard- 
ware fault occurs which is interpreted as a ring initiali- 
zation fault and triggers action of the kernel to initialize 
the ring. When the stack and the els for that ring are 
initialized, the kernel invokes the FSM. As stated in the 
general design, the FSM uses the fictive mapping table 
prepared by the prelinker to map the linker, the external 
data bases and the security kernel gates in the process 
address space. Finally the kernel copies the snapped 
links table built by the prelinker into the els just 
fabricated for the new ring. Control is then restored 
into the new ring. The linker has been mapped into the 
address space and its non-virgin linkage section contain- 
ing only snapped links exists in the els of the new ring. 
Thus the linker is operational in that ring. 

The last question which needs perhaps a brief comment 
is why do we need to invoke the FSM each time a ring is 
initialized in a process? Doing so for the first ring 
should be enough since the address space in which the FSM 
enforces the fictive mapping is the same for all other 
rings. Our implementation is justified by an aspect of 
the Multics virtual memory. In mapping a segment into a 
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segment number, one needs to specify the unique identifier 
of the segment and the ring on 1^half°o* Which the mapping 
is done. Once the bound linker for in&tattesr is mapped into 
its final address for one ring all rings Will see the 
address occupied but it will hot be meaningful to them 
until they also require the linker to W 1 mapped there on 
their behalf . 

This discussion completes the section on initialization 
of the kernel and of the linker. lt u ha¥ b%6h demonstrated 
that straightforward implementation 0* the design was 
possible on a computing utility like Multies. »o major 
probleitt and no particularly interesting Issue was raised 
so far. NoW we have shown how to impletafeiit ah operational 
linker, we Will proceed by shOWittg^hOW to invoke it in the 
faulting ring oh a link fault. - 

6. Fault Handling 

We have shown how the Multies dynamic linker was 
made operational in a ring. OuV next step Is to' Show how 
link faults are passed to it and to«r it can ietton control 
to the faulting object. Again this can be done by a 
straightforward application of the 1 design, using pre- 
existing mechanisms. 

All faults on Multies are intercepted By a special 
module of the kernel . This module existed already in the 
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initial version of Multics and its purpose is to analyze 
and sort faults. Just * few lines of code had to be 
modified so that link faults would be djjracted. to a sig- 
nalling module instead of being t directed, to,, a. ring. 
linker. The sj^fnalling nodule of the kernal. existed., as 
well in the initial version of Multics. It is already 
used to signal events other than link faults in outer 
rings* Because of the hierarchy of ri^gs*... the security 
kernel and the signalling .aodjule in ; j^ar4&c^iar '.can access 
any object in a higher numbered 'ring, and .can., switch the 
ring of exemption of a process _.. These. pj^vi^eges are 
exploited to signal a link fault. - Jf»(*% ,Py% signalling 
module receives a copy of the S8w#4ne, fta^us, saved by 
the fault interceptor module, i£ analy*®^ i<t to determine 
the number of the faulting ring, and the segment number 
of the stack used at fault time. Ifc. ,than, :? makes e stack 
frame for itself on that stack and co J?!# 8 Anto it the 
machine status. It copies as well a return .address to 
be used by the linker. It finally switches Mng of execu- 
tion and calls the linker. The ,addr#s*.,o£ : t*>e. linker is 
found in the stack header (conventional ... This address 
must be set at ring initialization and may be changed by 
the procese ,,i£ ..it .wants to defiae ? ,/aao.th^ir ...linker of its 
own in that ring. 
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Let us assume for a moment that we know how the 

linker itself works and suppose that it has snapped the 

faulting link and wants to restore control to the faulting 

object. The linker simply returns to the signalling module 

in the current ring. The signalling procedure then calls 

a gate into the kernel. The purpose of this gate is to 

/ 
validate the machine status returned to it by the signaller 

and to restore it. Validation simply consists in verifying 
that the status reflects a ring of execution not lower 
than the faulting ring. This is to make sure that the 
linker which handled the status in the faulting ring did 
not maliciously set it so that control would be restored 
in a lower numbered ring than the faulting ring, which 
of course violates protection. The gate then destroys 
the signalling stack frame in the faulting ring to make 
the stack look as if nothing had happened. Restoring the 
status is finally done in one indivisible hardware in- 
struction which reloads all the machine registers, thereby 
forcing control back into the formerly faulting object. 

7. The dynamic linker 

The last two sections have discussed respectively 
the prelinking of the linker and the handling of link 
faults. It remains to be demonstrated how the linker 
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itself can be implemented to translate links properly. So 
far the implementation did not encounter any major problem 
or any operation of outstanding interest. In this section 
we will only very briefly outline the implementation as 
a whole and then concentrate on selected interesting fea- 
tures of the Jtuities system of which the implementation 
cannot be derived directly from the global design princi- 
ples. As we mentioned it before, these selected topics 
are only instances of broader problems which any designer 
would face in any computing utility perhaps under differ- 
ent aspects. 

The starting point of the . implementation is the 
block diagram of figure 8. The basic dynamic linker is 
programmed according to the functional specifications of 
that diagram. This basic linker contains a dozen inde- 
pendent program modules. Once compiled, the resulting 
object segments are bound tx>gethe« by the binder. A 
bound object segment results which contains: about forty 
links to data bases and kernel gates and can itself be 
invoked through about fifteen dt^H&arentuearferlesi one of 
which is the main link translatdOtt en&cy used for link 
faults. 

On top of this basic linker we will now progressively 
add other features, functional boxes and specifications 
as we go about discussing specific implementation problems, 
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a. Implementation of peripheral features 

Let us first turn our attention to the question of 
static storage allocation. As we mentioned it in the 
chapter about the global d^Si%nv s^tic°storitfeS allocation 
is a general problem which must be solved in any computing 
utility. The wrong way of solving i%* i§\t# leave it in 
the responsibility of the linker. One cofrrect way to solve 
it is to install a hardware fault which wte called the! ISSP. 



When a process attempts to get a hold of the address of 
the static s%bra'ge ? (non-virgin linkage Wtk&lbh) *of the 
program it is executing and if that ^Stsatm is riot yet 
allocated, a ISSP occurs which triggers storage allocation. 
The old design of the Multics dynamic linker was such; that 
static storage allocation was part bf the .linked task; 
(alee figure 9)^ i5h snapping a linkj, th^lS^^uni«| linking 
driver used to always verify that the tlrl¥t "5F the link 
did have static storage in the target ring. As stated 
in the thesis, this design violates protection because a 
target object *n a target ring cannot depend on a faulting 
object in a faulting ring to use the linker and allocate 
static storage where appropriate. In addition, even if 
this was not a protection violation, it would simply be 
impossible for the new linker in a faulting ring to 
allocate space in a target ring if the target ring is 
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Figure 9: Old Multics dynamic linker. 
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lower than the faulting ring. This was possible in the old 
design because the linker was in the security kernel and 
could access any ring. 

Consequently we have proposed to implement a hardware 
ISSF as described, such that dynamic linking and static 
storage allocation are functionally distinct. Yet there 
is still one advantage in keeping them physically together 
(see figure 10). Keeping dynamic linking and static stor- 
age allocation physically together means keeping them in 
the same bound object segment, the bound linker. Thus 
they are prelinked and initialized together at the same 
time. Adding the static storage box in figure 10 increases 
the complexity of the dynamic linker but does not increase 
the complexity or modify the design of prelinking and ring 
initialization. 

The operation of the linker is thus as follows. 
Assume object A in ring 4 wants to invoke gate B in ring 
3. Whether A invokes B by symbolic name (link fault) or 
directly by its address it happened to already know is 
irrelevant. When execution moves to the target segment B 
in ring 3, as soon as segment B tries to find a presumably 
unallocated static storage, an ISSF occurs which results 
in the linker (static storage allocator part) to be 
invoked in ring 3. Allocation can and will thus safely 
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Ftgure 10: New Mul tics dynamic linker. 
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Flfcure 11: Static storage allocation on 
Multica 
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occur. This is pictured by figure 11. 

The problem of static storage allocation was just 
one example, and perhaps the most typical, of a feature which 
was hooked to the linker for convenience. Unfortunately, the 
linker was not the right place to hook that feature to. Other 
problems of the same kind were encountered during the implemen- 
tation. Just to mention a few we can cite trap handling and 
impure object segment handling. Such features are typical 
examples of sophisticated tools which have been hooked to 
the linker for convenience but do not actually belong 
there. Trap handling is a feature whiejt allows a program- 
mer to force execution of certain routines before his 
program can be called for the first time. The feature is 
named after the fact that it is based on trapping the first 
invocation of a program. Again the first invocation may 
not be a symbolic invocation; thus the linker can be by- 
passed; thus hooking the trap handling mechanism to the 
linker is just as disastrous as hooking static storage 
allocation to the linker. The solution is also to use a i 
hardware fault. We will not describe it here as it is 
really not part of the implementation of the linker. 
Impure object segment handling is a facility which pro- 
vides users with the ability of creating an object seg- 
ment and then writing into it perhaps over the definition 
and virgin linkage sections. Of course such an object 
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segment is not sharable. It is important to save the 
definition and virgin linkage section before they are 
overwritten (by copying them into the els before the first 
reference) . Such task was left to the linker. Again it 
did not belong there. By-passing the linker and thus not 
saving the definition and linkage sections could cause 
damage to the object segment. In addition it did put an 
extra burden on the linker by always forcing it to check 
for writeable object segments. The solution to the prob- 
lem is to always save the definition and virgin linkage 
sections of a writeable object segment in a separate seg- 
ment when the object segment is created. Compilers can 
take care of this very easily and already use such mechan- 
isms to handle other features on Multics. 

Static storage allocation, trap handling and impure 
Object segment are typical examples of peripheral features 
which have been hooked to the linker for convenience. As 
a result, they were mishandled, violated protection, com- 
plicated the linker and interfered with it performance. 
Our design has corrected that situation, 
b. Compatibility of interfaces 

We would now like to mention a second problem which 
the implementation encountered. This problem is specific 
to Multics but problems of the same kind would certainly 
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arise in any computing utility. The present problem does 
not have so much to do with the linker itself as it has 
with the general idea of pulling a module outside the 
kernel. 

Any program which is part of the kernel is very 
likely to use other functions of the kernel. In trying 
t? pul? 1 that .program outside t%» %erael# one must make 
sure that it still can use the other kernel functions as 
it did before. In the particu^r e«*s of the linker , the 
old Multics linker used the vm inside the security ker- 
nel. Of course, once the linker is pulled outside the 
kernel, it cannot call the ySH directly. All it can do is 
invoke, it through ajjprojpriate gates (see figure 12) . For- 
tunatejy the ,£«* of Multics was already available to the 
higher r in^s through such gates . m did not have to 
implement I 3 * 8 ** However the interface to $he FSM across 
these gates is not the same as the interface which the 
_linkfr r used £p p^ directly^ iffcSjLde ring, 0. .Directories 
are currently implemented as ring data bases. Their 
logical address in a process is also a protected item. 
yser >ria3f CI tp 7) may talk about diasectories only by 
treename and not by segment number, ©ijcectory segment 
numbers are exclusively used inside the kernel. Thus 
when the linker was inside the kernel, the search rules 



-101- 
Figure 12: Interface of the linker to the FSM, 
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it used across the interface with the PSM were a set of 
directory segment numbers. Now the linker is moved 
outside the kernel, directory segment numbers are not 
suitable directory tM±«jtie i^dfentifiers. Therefore the 
linker must use directory treenames. This implementation 
of search rules has the disadvantage that for each direc- 
tory searched or each link fault, the treename presented 
to the PSM gate must be converted into corresponding seg- 
ment number to perform the search. Such conversion is 
costly and has a negative effect on the performance of 
the linker. A parallel project is currently on its way 
to make directory segment numbers available in user rings. 
Such a design will restore the interface to the FSM which 
the linker used to see. However it has some major protec- 
tion implications. a of which the solution is not obvious. 
We will not discuss these implications here. 

The problem of the search rules was a typical 
example of a compatibility problem „ By removing the 
linker from the kernel, we were forced tK* make it compat- 
ible with the interface of the kernel seen by the user 
rings, 
c. Limitation of Privileges 

The last problem which we propose to discuss will 
illustrate the impact on the capabilities of a program 
of removing that program from the kernel. The problem 
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deals with snapping downward cross ring links, a feature 
which the ring"*thii* linker used to s^l^rt^ry easily- and 
which is now complicated by the tafet tAit^tne iinke* is in 
the faulting ring. " V '4 

in the general design described* earlier, the - PSM was 
described as a security kernel "primitiW'^Ica-- given a 
catalog unique identifier and an^^ect^ 
returns a logical^ addre%s L dft- MaltiesT- ! thi* ;, ia^nbt the 
exact function of Hhe tfSfc. Ifce *&& tftlriMk-* a da%e«t6ry 
treename and a segment name andTret£trni r a segment number. 
The difference between these ;; We 1 de»%rip*a.ons' -is- %ts*t a 
segment name is not an t^ect : ' ^sylttfadi^^inam^^airidF 5 * segment 
number is only a partial Idgiciaid^^Slsl T M^a cdfisequence 
a search of tnls o^inii:i6n s*etibn Ji d^ ^^ ^sjrgert* segment 
must be performed to find th6 ^f f **& o^^the ^target object 
in the target s#gm%nt tsetf f£gTttr#^ . M " 1«ilfib? ®i¥ target 
object iS in a ring «qual to l 6r- higliel^^a^St ^x# faulting 
ring, such search poses no ^pr^SI*itf^ T: %u¥wBferf ^he target 
object is a gate into a ring ^SoWer 1 : '¥KetfWi Stilting ring , 
the linker in the faulting ring? «bW «* 1i*Wal-»«iW 
capability to reaW or search ; ^We ^r^efc :*U*gmatFt . «*e old 
linker executing iftt the 4 kernel *&a"h*ffc t «&*t *fc*paJ*il£ty. 

When snapping W link to A a "*$£m ''in*© '■•* 4e*er $iimfcered 
ring, the linker rautft • extract ;T iaie c ^fr¥#fe^f l -mtM J&V* 
from information contained in ^ lh# iiar^e^ ^e^gmerit 
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containing the gate* The paly ,, way t©. extract information 
from that target segment is t» ^^t c |W»Pth#3c g»t«, a 
linker gate, into the target ring. The function of the 
linker grata is equivalent to the fuaction of the "entry 
search driven " in figure 8. , .$ut., the. afarch, happens in 
the target ring instead of happening in the faulting ring. 
The gueetioa which the ref^e^ L isj nc^ entit|e4 t© ask 
is how does the n linker knew &gBk ri $^£ii$^.gjti^J^..th* 
first place? There ere .several J£Sffffe£*« answer*, to this 
question.. One way the linker coj^keofiaJtot £t i* by 
conventions. It would he possibl e to,, iapoae that ...any 
rin^^ontmin a gat* na#*»d .afto*. AMf"l» f**W» Jiuebe^Land 
. located- i^ a segment of soate convent, toRaJ directPry > , 
The looker could, then invoke the WSH jje,. obtain .*, segment 
by gAvi^ft the #SK the name of ,Jshe oonventional directory 
and the consantional nane of the- .#•££ .JLato. the; target 
ring. It would thus reoeiy^A nejpeent, .njpber.. Then* 
using a conventional of feet into ,.fch*t segment, it #sould 
dynamically fabricate for .itself ,.^-ainkj. to. the. .linker 
gate . Such design %m feasible and, vejry, appropriate if 
-.there, was * Large number o£ rings per process- . Jiowever 
we keow-^that,' the .^wptoax -of xing»_ j|er,,|ircceas .iSj .finite. 
Thu* t|hee*) r i«4*jB*{&;j^^ ©roblem which 

consist* in »r**viding -the ^standa^,,^l : ^c^ ;i ,s^ptem with a 
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finite set of gates (one per ring) , loading these gates 
into the machine during system initialization, prelinking 
the linker to each such gate as usually and throwing the 
gates out of the kernel address space after prelinking. 
This is the solution which was implemented on Multics. 
It is pictured in figure 13. During system initialization, 
the linker is prelinked to the FSM gates as well as to 
one linker gate for each ring. Then when A takes a link 
fault in trying to call gate B, the linker is invoked in 
ring 4. It obtains a segment number s for B from the FSM. 
The FSM also tells it that B is a gate into ring 3. 
Instead of calling the entry search module in ring 4 , the 
linker then calls the linker gate in ring 3. The linker 
gate can search the oject segment B and thus returns the 
offset w of b in B to the linker in ring 4. 

The last problem discussed was an example of a case 
where by being removed from the kernel, a program, the 
linker, lost privileges which it used to exploit to per- 
form its task. Other such examples were encountered 
during the implementation. For instance, the linker used 
to store in a system wide data base, various meters count- 
ing the number of link faults, the distribution of pro- 
cessing time required, etc. Data could be extracted from 
that data base by anybody interested in performance. Of 
course, now the linker is in user rings it could still do 
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Flgure 13: Cross ring linking In Multics 
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such metering, but results could not be trusted because 
the system wide data base would have to b^ accessible in 
user rings too. kehce anybody could write r garbage into 
it. The solution which we propose" instead ii to just 
keep a count of link faults in ring £ t). ' Tfiis is done by 
the fault interceptor module. The count is* thus protected. 
Other meters can be stored in per ring data bases if the 
user desires. Such meters woula; of :: course reflect only 
the activity of that user in that ring." 1 

This is the last problem we propoiWa" tcf present here 
about the implementation. In nb waf do* we suggest that 
the implementation faced no more problems *1±Can explained 
here. The problems presented here wefir ^st' typical 
examples representative of classes of p^obleitHr relevant 
to the topic of our research. Problems riet discussed 
here either fell into categories for Which we have given 
examples or into categories hot relevant: to our thesis 
topic. 
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v. Conclusion 

To conclude this thesis, we would like to step back 
and consider the design and * its ;. ;^^;|e^Bentf tjlon as a whole 
to summarize what has been achieved, try to abstract the 

main results of the thesis / and, ea^Bine thf cost of the 
implementation. 

We first propose to compare the old design of 
with the new design we have implemented. Our comparison 
is based on figure 14. The old dynamic y.nker was part of l 
the security kernel, It was cxjaatl^Ul^C by a set of 
modules scattered across the whoJ#„ ;; kernel,, _ Some of these 
modules were directly available to the :: _ u»f r through appro- 
priate gates into the kernel (see |$^en<fL||c> . Miscellaneous 
perigpheral functions like static atc^age allocation and 
trap handling were directly hooked t|» the linker inside the 
kernel. The new dynamic linker is ft bound object segment. 
Capabilities to use it exist in all rings except ring 0. 
The modules of the dynamic linker which used to be available 
through gates in the kernel are now directly available in 
user rings. All peripheral features have been detached 
from the linker and are now handled independently as 
described earlier. The static storage allocator is still 
physically connected to the linker to simplify initialization, 
but it is functionally independent: its operation is 
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triggered by a special hardware fault. As a result of the 
above facts the complexity of the security kernel has been 
reduced by a non-negligible, although hard to measure, 
amount. What can be measured is the reduction of the size 
of the kernel. The following items have been extracted 
from the kernels 

15000 words out of 300000 (5%) , 
30 entries out of 1200 (2. Ml, 
15 programs out of 300 (5%) , 
18 gates out of 165 (11%). 

The case of the gates is particularly interesting. Since 
the linker has been removed from the kernel, all gates 
which used to lead to it inside the kernel could be 
removed too. The figure of 11% deserves a special comment. 
Since the interface between the kernel and the outer world 
is one of the most sensitive, directly threatened part of 
the kernel, a reduction of size of 11% is a significant 
improvement. We attribute this high score to the fact 
that the linker was, as we have shown, essentially a user 
ring program. Thus even though it was in ring 0, it was 
natural that it be available to user rings through many 
gates . 
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Secondly we propose to discuss the results of the 
thesis. A first result is the demonstration of the 
feasibility of the design. Some components of the design 
have not been implemented because they were thought to be 
of minor importance and could not have any impact on the 
overall success of the implementation. Other components 
of the design like the functional independence of the 
static storage allocator could not be implemented simply 
because the supporting hardware is not yet available on 
Multics. However it was approximated by software and 
when the hardware becomes available , only a simple change 
of a few lines of code is required to separate static 
storage allocation from dynamic linking. On the whole thus 
the major aspects of the design and of the implementation 
have been verified to work correctly. System initializa- 
tion, fault handling and dynamic linking have been imple- 
mented. All features crucial to the operation of the 
linker itself have been extensively tested and proved to 
work under all circumstances. In particular cross-ring 
linking was carefully tested. 

The second result of the thesis is the improvement of 
the protection and the certifiability of the kernel of 
Multics. Size and complexity have been reduced in the 
proportions mentioned above thereby making the auditing 
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of the kernel an easier task. In addition, the thesis 
has corrected seats bugs in-' tad MultlCs system, the 
protsction threat resulting fro* having peripheral features 
hooked to the linker has been eliminated. ¥he protection 
of the kernel itself is no mo ire threatened by the uncon- 
trollable operation of the linker. 8©xee*errthe careful 
study and the redesign of the ii8*#r v u»^ii*rsd and 
remedied several unsuspected protection flaws, not the 
least of which is the problem #f static storage allocation. 

The -last mejce results worth eentioning here are the 
insights gained about the nature of a kernel. Although 
the thesis has not provided any definition of what 
programs belong inside th* hash*!, It ceirtei»ly has pro- 
vided a few. insights about what programs can easily be 
"»ved outside the kernel. - The- a- p^Miie#i«i?i' •ariSlysi* of 
the linker -has revealed a few interesting features which 
at the same time nade the linker ah easy to remove pro- 
gram and are a direct result of its ussr -"rihg nature. 
We do not suggest in any way tbat-ellr programs exhibiting 
the features to be described should or- oven could be 
removed from the kernel. MS only suggest that Such pro- 
grams are certainly better candidates for removal than 
others end that any attempt to simplify a kernel should 
start by examining such programs. - 
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The first feature which made the linker a good can- 
didate for removal is the number of gates which lead to 
it inside the kernel. As we already suggested, this fact 
is most probably connected to the user ring nature of the 
linker. A program which is already available to user 
rings through many gates is inside the kernel but close 
to the outside world. Pulling it out should in general 
be easier than pulling out a program deeply nested inside 
the kernel (see figure 15) . 

The second feature of the linker which made it a good 
candidate for removal is the fact that it was not used to 
support any other kernel function. In figure 15, program 
B is callable through a gate. Thus according to our first 
criterion, it should be easy to remove it. However B is 
needed to support A (invoked by A) inside the kernel, and 
A is not available through a gate. Hence it is probably 
hard to pull A outside the kernel and B has to stay 
inside as well. This does not mean that B can never be 
executed in a user ring when invoked by a user ring, but 
it implies it must still be part of the kernel and thus 
audited to support the operation of A. In the case of 
the linker, since no other function like A used it, it 
could easily be removed. 

The third interesting feature of the linker is that 
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Flgure 15: Multios securl ty kernel 
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all kernel primitives (e.g. the FSM) it used to invoke 
from inside ring were already available to user rings 
through gates. Thus removing it simply moved back the 
boundary of ring without even creating new gates through 
it. Instead removing Z from the kernel in figure 15 would 
require a gate to be added to reach X because X is not yet 
available in the user rings. 

The last three paragraphs have described overall 
features of a program which make it a good candidate for 
removal. Of course further functional investigation may 
reveal that such a program cannot possibly be removed simply 
because it deals directly with protection and is a proper 
component of the kernel. 

We finally would like to examine the cost of our 
implementation: how much did the removal of the linker 
alter the performance of the system? Given that performance 
and performance evaluation were not among the goals of our 
thesis, we will not present an exhaustive performance study 
of the linker. However we have run a few simple performance 
tests which consisted simply in measuring the time required 
to snap "average" links. By "average" we mean links of the 
type most frequently handled by the linker. That is links 
not going cross-ring and not using any sophisticated features, 
The measurements were taken in two different cases. First, 
we measured the time required to snap a link to an object 
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currently mapped in the logical address space. Secondly, 
we measured the tine required .*©..• snap*;*, link to an object 
not currently mapped in the log is*!, address space. Such 
measurements were carried- on fiosr both tee old linker and 
the new linker* 

In the first case, the new linker requires 10 more 
milliseconds than the old linker, which - .trnptmrnmotm an 
increase of 40 to 6.0 percent of the-total-* time required 
by the old linker to snap the link. 3Stie fixed increase 
in time is independent of the amount of processing 
required to handle the link itself . lie at*ri.bute it to 
the fixed overhead involved in signalling the link fault 
in the faulting ring, invoking *ecur£*af kernel primitives 
through gates, and r#questi$*g the, .kernel to validate and 
restore the machine status. Ml :|^heseEs i «f«ra*ions are 
required for the new linker to,,-ope«aitoe^and' ware not 
required or not so complicated with the:; privileges of the 
old linker* fhis increased overhead :.*a the basic price 
paid by our design* 

In the case of the second set of measurements, the 
new linker requires roughly twice *s rauch ;$&m as the old 
linker does. Such overhead im -not:, a.- £*#**%? overhead 
although it contains the^ fixe4.-Over.hes4 of 10 milliseconds, 
Instead this overhead is relatively proportional to the 
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length of the search for the target object in the file 
system. In order to speed up the search for and mapping 
of a target object, it is standard practice on Multics 
to first look in the logical address space in case the 
object is already there. The first set of measurements 
corresponds to this case. Only if the object is not found 
in the address space is the FSM invoked to search the file 
system. The reason why this search is roughly twice as 
long for the new linker as it used to be for the old one 
is mainly because search rules are now directory treenames 
instead of directory segment numbers. As we mentioned it 
earlier, we expected this to yield a non-negligible 
overhead because translation of a treename to a segment 
number prior to each directory search is very expensive. 
Fortunately, when the project of removing name space 
management from the kernel is finished, we will be able to 
restore the search, rules under their old form and the per- 
formance will no more suffer from the overhead described 
above . 

To conclude the discussion of performance, it must be 
said that clearly some fixed overhead (10 ms) was paid by 
the new design. However the overhead in the search is a 
price paid only temporarily. In addition it is believed 
that the figures presented can be improved. They are the 
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results of very rough measurements; a more careful analysis 
is clearly needed to identify the bottlenecks in the new 
linker and try to optimise the code there. Also, when 
static storage allocation, trap handling and other features 
will be separatee from the linker em recommended, the 
performance of the linker is likely to increase signifi- 
cantly because it will no more have t© check and worry 
about all such peripheral features. Thus the performance 
perspective is not as bleak aa the above figures seem to 
suggest. 

Summary 

This thesis has attempted to open a road towards 
security kernel simplification by removing the dynamic 
linker from the security kernel of a computing utility. 
A second wave aimed at simplification of the kemal is now 
on its way to -remove name space management from the 
security kernel. Ho matter how large an effort these two 
first simplifications will have required, this effort is 
almost negligible in comparison to what remains to be done. 
Even when we will have reached the minimal definition of a 
security kernel, the hardest part of its certification will 
remain to be worked out: the auditing. There exists so 
far no formal theory of kernel auditing. While program 
verification techniques are a first step towards kernel 
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auditing, they are not the panacea. Auditing a kernel is 
much harder than auditing the sum of its program components 
because of all hidden interactions between these components, 

Yet because of the increasing need for security and 
reliability of information stored in a computing utility, 
more powerful and carefully verified protection mechanisms 
are demanded. Protection of information is not only the 
fact of defense, census, medical or criminal information 
systems. It is a vital characteristic required by our 
society from any information storage system, computers 
not in the last place. Thus it is worth paying the price 
of certification to satisfy the fundamental need for 
true protection. 
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Appendix: Gates removed from the Mul tics security kernel 

To illustrate the variety and the number and the 
complexity of the functions removed from the Multics 
kernel by the implementation described in Chapter IV, 
we list here all gates removed from the kernel with their 
respective description. 

assign_linkage 

allows the user to request the static storage 

allocator to allocate a given amount of space in 

the els of the requesting ring. A pointer to 

the allocated space is returned; 

f s_search_getjwdir 

allows the user to ask the treehame of his current 

working directory. The working directory is used in 

the search rules and can be any directory so defined 

by the user; 

fs__search_set_wdir 

allows the user to define his new working directory; 

get_coun t_l inkage 

allows the user to obtain a pointer to the static 

storage of a segment given a pointer to and the 

bitcount of that segment; 
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get_defname__: 

is a generalization of get_entry_name for entries 
not necessarily into executable programs; 
get_entry__name : 

allows the user to find out the name of an entry into 
a program given a link to that entry; 
get_linkage : 

is essentially the same as get__count_linkage but does 
not require the bitcount of the segment under concern; 
get__lp: 

allows the user to get a pointer to the static stor- 
age of a program in the requesting ring given a 
pointer to the segment containing the program; 
get_rel_segment : 

allows the user to get a pointer to the definition 
or the linkage section of a segment given a pointer 
to the segment; 
get_search__rules : 

allows the user to find out what his current search 
rules are; 
get_seg_count : 

allows the user to get a pointer to and the bitcount 
of a segment given the segment name; 
get_segment : 
same as above but doesn't return the bitcount; 
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initiate_searchjrules . 

■" allows"- the- use* : to de# laii^iMMt > s eadpefc §«*!#*•> -and enable 
them in-t^- s '«tirr%i^-«ifwS;- : »'';> f'^n-v-ca.^v^ 
link_£©rGe: :.?xi± 

i«i ■*:.■/ * static liiflcing" ea*aeyci»- *fcfc sSyBflwaic linker ; . 

nkke^fcr*. - - -»> 

allx^rthep-uservtO''' fa b ri ca t e : a fifciaifce&^ivev- a, link) 

to an ob jecfc f ro» scratch, ;- apUvta: taiiat^aibolic aame 

of the object; 

rest_of __datmk : 

allows the user to grow a data object under a given 

symbolic name if that object doesn't exist yet. This 

is a gate into one of the sophisticated feature 

handler hooked to the linker; 

set_lp: 

allows the user to set the static storage pointer for 

a given program in the current ring; 

unsnap_service : 

allows the user to undo the work of the linker by 

unsnapping any link the linker may have snapped in 

the requesting ring to a given entry. 
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We hope this exhaustive list of once gate* into the 
linker has convinced the reade* of 1*e vsxiety and the 
complexity of the linker interfaee.- This is one of the 
reasons why it wm.:am*fb- ^esiTSh.lft aad cevsusding to 
remove l£<-4Esesi the kernel. I& addition to having to 
audit 18 crates into the kernel, on the average 4 arguments 
per gate had to fee validated, wnioh incaMwaed the complexity 
and thn certification prohles eiaut move, -^ 
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